在程序开发中怎样写SQL语句可以提高数据库的性能
SQL语句查询性能优化
SQL语句查询性能优化
SQL查询性能优化是针对数据库查询操作的一系列技术和方法，旨在
提高查询的执行效率和性能。
以下是一些常见的SQL查询性能优化技术和
方法：
1.使用索引：在查询中使用适当的索引可以加快数据库的查询速度。
根据查询的字段和条件，创建适当的索引可以减少数据库扫描的记录数，
提高查询效率。
2.避免使用过多的连接查询：连接查询（JOIN）可能会导致查询性能
下降，尤其是在连接的表中有大量的数据时。
如果可能的话，可以将连接
查询拆分为多个简单的查询，或者使用子查询等替代方案。
3.优化查询语句：可以通过修改查询语句来提高查询性能。
例如，使
用合适的WHERE子句和条件，避免不必要的列和行，使用聚合函数等。
4.避免使用通配符查询:在查询语句中避免使用通配符（如%），因为
通配符查询会导致全表扫描，降低查询性能。
5.合理规划数据表结构：合理的数据库表设计可以提高查询性能。
例如，使用正确的数据类型，避免冗余字段和表的设计，以及正确的数据库
范式等。
6.定期维护数据库：定期进行数据库优化和维护任务，例如索引重建、表碎片整理等，可以提高查询性能。
7.使用数据库性能分析工具：使用数据库性能分析工具可以帮助识别
慢查询和性能问题，并提供优化建议。
8.增加服务器硬件资源：如果数据库查询性能仍然不足，可以通过增加服务器硬件资源来提升性能，例如增加CPU、内存、磁盘等。
以上是一些常见的SQL查询性能优化技术和方法，根据具体的情况和需求，可以选择适当的方法进行优化。
如何写出高效的SQL查询语句
如何写出高效的SQL查询语句在现代的数据库应用程序中，SQL（Structured Query Language）查询语句是非常重要的一部分。
一条高效的SQL查询语句可以大大提升数据库的性能，减少查询时间，提高用户体验。
本文将探讨一些编写高效SQL查询语句的技巧和方法。
1. 选择合适的索引索引是数据库中提高查询性能的重要工具。
在编写SQL查询语句时，应该根据查询的字段和条件选择合适的索引。
索引可以加快查询速度，减少数据库的扫描时间。
但是，过多的索引也会降低性能，因此需要权衡选择。
可以使用EXPLAIN 语句来分析查询语句的执行计划，查看是否使用了正确的索引。
2. 避免使用通配符查询通配符查询（如使用LIKE语句）会导致全表扫描，影响查询性能。
如果可能的话，应该尽量避免使用通配符查询。
可以考虑使用前缀索引或全文索引来提高查询效率。
3. 使用JOIN语句JOIN语句可以将多个表连接在一起，实现复杂的查询。
在使用JOIN语句时，应该注意选择合适的连接方式和连接条件。
使用内连接（INNER JOIN）可以排除不必要的数据，提高查询效率。
同时，应该避免多层嵌套的JOIN语句，这样会增加查询的复杂度和执行时间。
4. 优化子查询子查询是一种常见的查询方式，但是如果使用不当，会导致性能问题。
在编写子查询时，应该尽量减少子查询的嵌套层次，避免在子查询中使用不必要的函数和操作。
可以考虑使用临时表或表变量来优化复杂的子查询。
5. 使用合适的数据类型在定义数据库表时，应该选择合适的数据类型。
使用合适的数据类型可以减小数据库的存储空间，提高查询速度。
例如，使用整型数据类型代替字符型数据类型可以节省存储空间和提高比较效率。
6. 编写优化的SQL语句在编写SQL查询语句时，应该尽量避免使用SELECT *，而是明确指定需要查询的字段。
这样可以减少网络传输的数据量，提高查询效率。
同时，应该合理使用聚合函数和GROUP BY语句，避免不必要的计算和分组操作。
SQL语句性能调优的实用技巧与方法
SQL语句性能调优的实用技巧与方法在数据库应用开发过程中，SQL语句的性能调优是一项重要而复杂的任务。
通过优化SQL语句的执行效率，可以提升数据库的整体性能，并且减少系统响应时间。
本文将介绍一些实用的SQL语句性能调优技巧和方法，帮助开发人员高效地优化SQL查询。
一、正确使用索引索引是提高SQL查询性能的关键因素之一。
当数据库中的表较大时，使用索引可以大幅度缩短查询的执行时间。
选择合适的索引字段以及创建并维护适当的索引是SQL性能调优的首要步骤。
1. 分析查询字段和条件：分析查询语句中经常用于过滤或排序的字段和条件。
选择这些字段作为索引字段，可以大幅度提高查询效率。
2. 避免过多和重复索引：创建过多的索引会增加数据库的维护成本，降低写入性能。
因此，只选取最为重要和频繁使用的字段创建索引，并避免创建重复的索引。
3. 定期更新索引统计信息：索引并不是一成不变的，随着数据量的不断增长和数据更新的频率，索引的统计信息需要定期更新，以确保查询优化器能够正确选择最优的索引。
二、合理优化表结构在设计和使用数据库表的过程中，合理的表结构设计对于SQL查询的性能影响很大。
以下是几点值得注意的建议。
1. 规范数据类型选择：选择合适的数据类型，可以在一定程度上减少空间占用，并提高查询效率。
例如，使用CHAR类型存储长度固定的字符串，使用VARBINARY存储二进制数据等。
2. 减少冗余字段：合理设计表结构，在避免冗余字段的前提下，提高数据表的规范化程度。
冗余字段不仅浪费存储空间，而且会增加数据更新的复杂性，降低查询效率。
3. 数据拆分和分区：当表的数据量很大时，可以考虑根据数据的特点进行拆分和分区，如按年份、地区等进行分区存储。
这样可以提高查询效率，减少锁竞争。
三、合理优化查询语句SQL查询语句的编写方式和查询逻辑对于整体性能也有很大的影响。
下面是几个优化查询语句的建议。
1. 避免全表扫描：尽量避免使用不带索引的查询语句，因为这种查询方式需要对整个表进行全表扫描，影响查询性能。
sql 高阶写法
sql 高阶写法
SQL高阶写法通常是指使用复杂的查询语句来实现一些特殊
需求或优化查询性能。
下面是一些常见的SQL高阶写法示例：
1. 使用联合查询：使用UNION或UNION ALL关键字可以将
多个查询结果合并成一个结果集。
UNION会去除重复的行，
而UNION ALL保留重复的行，所以如果确定结果不会有重复，可以使用UNION ALL来提高查询性能。
2. 使用子查询：使用子查询可以在一个查询中嵌套另一个查询，从而实现更复杂的查询逻辑。
子查询可以用于过滤数据、计算列、作为表的源等。
3. 使用窗口函数：窗口函数是一种高级函数，可以在查询结果中对每条记录应用一个函数，并计算出指定窗口范围内的结果。
窗口函数可以用于计算排名、分组运算等。
4. 使用临时表或表变量：创建临时表或使用表变量可以在查询中存储中间结果，从而简化复杂查询逻辑或提高性能。
临时表和表变量可以通过INSERT、SELECT等语句操作，可以在使
用完后自动删除。
5. 使用索引：为重要的查询字段创建索引可以大大提高查询性能。
可以创建单列索引、复合索引、全文索引等形式的索引来满足不同的查询需求。
然而，过多的索引也可能影响写入性能，需要根据实际情况权衡。
这些是SQL高阶写法的一些示例，具体的应用和实现方式会根据具体的需求和数据库系统而有所不同。
需要根据实际情况选择合适的写法来解决问题或优化查询性能。
如何编写高效的SQL查询语句
如何编写高效的SQL查询语句编写高效的SQL查询语句需要考虑多个方面，包括优化查询结构、选择合适的索引、避免全表扫描以及合理使用连接等。
以下是几个编写高效SQL查询语句的建议：1.优化查询结构：根据实际需求，尽量简化查询语句的结构，减少不必要的表关联和条件限制。
同时，尽量将复杂的计算或操作封装在数据库存储过程或函数中，减少重复计算。
2.使用合适的索引：针对频繁查询的字段，使用适当的索引可以大幅提高查询效率。
索引可以加速where条件中使用的列，但过多的索引可能导致性能下降和存储开销增加，因此需要权衡索引的数量和在哪些列上创建索引。
3.避免全表扫描：尽量避免全表扫描，即尽量避免在查询条件中使用无索引的列或使用不等于（!=）等会导致全表扫描的操作符。
在查询语句中使用合理的条件限制，以尽量缩小查询范围。
4.合理使用连接：在使用表连接时，选择合适的连接类型（如内连接、外连接），并确保连接列已经创建了索引。
对于大型表的连接操作，可以考虑使用子查询或者临时表来优化性能。
5.避免使用SELECT *：明确需要查询的列，并尽量避免使用SELECT *查询所有的列。
只查询需要的列可以减少数据库传输的数据量，提高查询效率。
6.分页查询优化：对于需要分页查询的情况，可以使用LIMIT语句来指定查询的起始位置和数量，避免一次性查询大量数据。
7.定期优化数据库：定期进行数据库性能优化，包括重新生成索引、清理无用数据、重新规划表结构等。
请注意，以上建议是一些常用的优化技巧，具体优化方法需要根据实际数据库结构、数据量和查询需求来调整和应用。
同时，数据库服务器的硬件性能和配置也会影响查询性能，因此综合考虑软硬件因素是编写高效SQL查询语句的关键。
如何优化SQL语句提高数据库查询效率
如何优化SQL语句提高数据库查询效率在当今数字化的时代，数据库成为了企业和组织存储和管理大量数据的核心工具。
而在与数据库进行交互的过程中，SQL 语句的性能直接影响着系统的响应速度和用户体验。
优化 SQL 语句以提高数据库查询效率是一项至关重要的任务，下面我们就来探讨一下如何实现这一目标。
首先，理解数据库的架构和表结构是优化的基础。
在开始优化之前，要清楚地知道数据是如何存储的，表之间的关系以及索引的设置情况。
例如，如果一个表经常用于关联查询，那么为相关列创建合适的索引可以显著提高查询速度。
索引是提高查询效率的关键因素之一。
但并不是索引越多越好，过多的索引会增加数据插入、更新和删除的开销。
因此，要根据查询的频繁程度和数据的特点有针对性地创建索引。
通常，在经常用于查询条件、连接操作和排序的列上创建索引是比较明智的选择。
避免在大表上进行全表扫描是优化的重要策略。
如果查询语句没有使用到索引，数据库就不得不逐行扫描整个表来获取所需的数据，这会导致性能急剧下降。
所以，在编写查询语句时，要尽量确保能够利用到已创建的索引。
对于复杂的查询，分解为多个简单的查询有时会更有效。
将一个大而复杂的查询分解为多个较小的、更具针对性的查询，可以减少数据库的负担，并且更容易理解和优化每个部分。
在条件查询中，要注意条件的写法。
避免使用模糊匹配（如｀LIKE ＇％value%＇｀），除非确实必要。
因为这种写法通常无法利用索引，导致全表扫描。
尽量使用精确匹配（如｀＝｀）或者范围匹配（如｀BETWEEN`），以便数据库能够使用索引快速定位数据。
合理使用连接（JOIN）操作也能提高效率。
在多表连接时，要确保连接条件准确无误，并且根据数据的分布和查询的需求选择合适的连接类型（内连接、左连接、右连接等）。
在查询中，只选择需要的列而不是全部列可以减少数据的传输量，从而提高性能。
特别是在处理大型数据表时，这一点尤为重要。
避免使用子查询，特别是复杂的子查询。
SQL查询语句性能优化
SQL查询语句性能优化SQL查询语句性能优化在开发和维护大型数据库系统时，SQL查询语句的性能优化是至关重要的。
一个高效的查询语句可以显著提高系统的性能，并减少用户等待时间。
本文将介绍一些常见的SQL查询语句性能优化技巧，帮助您提高数据库系统的性能。
1. 使用索引：索引是提高查询效率的关键。
通过在查询语句的关键列上创建索引，可以加快数据的检索速度。
但是需要注意，不要滥用索引，过多的索引会增加数据插入和更新的时间。
2. 避免使用通配符查询：通配符查询（如LIKE '%value%'）会导致全表扫描，从而严重影响查询性能。
如果可能的话，尽量避免使用通配符查询，或者考虑使用全文索引来优化。
3. 减少查询结果集的大小：只返回必要的列，并且使用LIMIT或TOP子句来限制查询结果的返回数量。
这样可以减少网络传输的压力，提高查询性能。
4. 使用连接查询：连接查询（JOIN）是将多个表连接起来进行查询的一种方式。
使用连接查询可以减少多次单表查询的开销，提高查询效率。
但是需要注意，连接查询需要谨慎使用，过多的连接操作可能会影响查询性能。
5. 使用子查询：子查询是嵌套在主查询中的查询语句，可以在不同的场景中提高查询性能。
例如，可以使用子查询来替代多次查询相同的表。
6. 避免使用ORDER BY：ORDER BY子句会对查询结果进行排序，可能会导致较高的性能开销。
如果不是非常必要，尽量避免使用ORDER BY，或者在必要时使用LIMIT来限制排序的范围。
7. 使用存储过程：存储过程是一组预编译的SQL语句，可以通过一次调用执行多个查询操作。
使用存储过程可以减少网络传输的开销，提高查询性能。
8. 定期优化数据库：定期进行数据库的优化工作是保持查询性能的关键。
可以定期清理无用的索引和查询语句，重新组织表的物理结构，以提高查询效率。
综上所述，SQL查询语句的性能优化是数据库系统中不可忽视的重要环节。
通过使用索引、避免通配符查询、减少查询结果集的大小、使用连接查询、使用子查询、避免使用ORDER BY、使用存储过程和定期优化数据库，可以显著提高数据库系统的性能，提升用户体验。
在程序开发中怎样写SQL语句可以提高数据库的性能
作者: 树下来源: 博客园发布时间: 2011-02-13 18:20 阅读: 168 次原文链接全屏阅读 [收藏]编辑点评：如何才能写出高性能的SQL语句，以下的十三条法则值得你去注意。
比如什么是执行计划？为什么要统一SQL语句的写法等等。
1、首先要搞明白什么叫执行计划？ 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个10万条记录的表中查1条记录，那查询优化器会选择索引查找方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用全表扫描方式。
可见，执行计划并不是固定的，它是个性化的。
产生一个正确的执行计划有两点很重要： (1) SQL语句是否清晰地告诉查询优化器它想干什么？ (2) 查询优化器得到的数据库统计信息是否是最新的、正确的？ 2、统一SQL语句的写法 对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。
1. select*fromdual2. select*Fromdual 其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。
生成2个执行计划。
所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！ 3、不要把SQL语句写得太复杂 我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。
一般来说这么复杂的语句通常都是有问题的。
我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。
可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。
一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化器就很容易给出错误的执行计划。
因为它被绕晕了。
像这种类似人工智能的东西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1、首先要搞明白什么叫执行计划? 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用“全表扫描”方式。
可见，执行计划并不是固定的，它是“个性化的”。
产生一个正确的“执行计划”有两点很重要： (1) SQL语句是否清晰地告诉查询优化器它想干什么? (2) 查询优化器得到的数据库统计信息是否是最新的、正确的? 2、统一SQL语句的写法 对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。
select * from dual Select * From dual 其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。
生成2个执行计划。
所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行! 3、不要把SQL语句写得太复杂 我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。
一般来说这么复杂的语句通常都是有问题的。
我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。
可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。
一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化器就很容易给出错误的执行计划。
因为它被绕晕了。
像这种类似人工智能的东西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。
另外，执行计划是可以被重用的，越简单的SQL语句被重用的可能性越高。
而复杂的SQL语句只要有一个字符发生变化就必须重新解析，然后再把这一大堆垃圾塞在内存里。
可想而知，数据库的效率会何等低下。
4、使用“临时表”暂存中间结果 简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。
5、 OLTP系统SQL语句必须采用绑定变量 select * from orderheader where changetime > ‘2010-10-20 00:00:01’ select * from orderheader where changetime > ‘2010-09-22 00:00:01’ 以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。
如果采用绑定变量 select * from orderheader where changetime >@chgtime @chgtime变量可以传入任何值，这样大量的类似查询可以重用该执行计划了，这可以大大降低数据库解析SQL语句的负担。
一次解析，多次重用，是提高数据库效率的原则。
6、绑定变量窥测 事物都存在两面性，绑定变量对大多数OLTP处理是适用的，但是也有例外。
比如在where条件中的字段是“倾斜字段”的时候。
“倾斜字段”指该列中的绝大多数的值都是相同的，比如一张人口调查表，其中“民族”这列，90%以上都是汉族。
那么如果一个SQL语句要查询30岁的汉族人口有多少，那“民族”这列必然要被放在where条件中。
这个时候如果采用绑定变量@nation会存在很大问题。
试想如果@nation传入的第一个值是“汉族”，那整个执行计划必然会选择表扫描。
然后，第二个值传入的是“布依族”，按理说“布依族”占的比例可能只有万分之一，应该采用索引查找。
但是，由于重用了第一次解析的“汉族”的那个执行计划，那么第二次也将采用表扫描方式。
这个问题就是著名的“绑定变量窥测”，建议对于“倾斜字段”不要采用绑定变量。
7、只在必要的情况下才使用begin tran SQL Server中一句SQL语句默认就是一个事务，在该语句执行完成后也是默认commit的。
其实，这就是begin tran的一个最小化的形式，好比在每句语句开头隐含了一个begin tran，结束时隐含了一个commit。
有些情况下，我们需要显式声明begin tran，比如做“插、删、改”操作需要同时修改几个表，要求要么几个表都修改成功，要么都不成功。
begin tran 可以起到这样的作用，它可以把若干SQL语句套在一起执行，最后再一起commit。
好处是保证了数据的一致性，但任何事情都不是完美无缺的。
Begin tran付出的代价是在提交之前，所有SQL语句锁住的资源都不能释放，直到commit掉。
可见，如果Begin tran套住的SQL语句太多，那数据库的性能就糟糕了。
在该大事务提交之前，必然会阻塞别的语句，造成block很多。
Begin tran使用的原则是，在保证数据一致性的前提下，begin tran 套住的SQL语句越少越好!有些情况下可以采用触发器同步数据，不一定要用begin tran。
8、一些SQL查询语句应加上nolock 在SQL语句中加nolock是提高SQL Server并发性能的重要手段，在oracle中并不需要这样做，因为oracle的结构更为合理，有undo表空间保存“数据前影”，该数据如果在修改中还未commit，那么你读到的是它修改之前的副本，该副本放在undo表空间中。
这样，oracle的读、写可以做到互不影响，这也是oracle广受称赞的地方。
SQL Server 的读、写是会相互阻塞的，为了提高并发性能，对于一些查询，可以加上nolock，这样读的时候可以允许写，但缺点是可能读到未提交的脏数据。
使用nolock有3条原则。
(1) 查询的结果用于“插、删、改”的不能加nolock ! (2) 查询的表属于频繁发生页分裂的，慎用nolock ! (3) 使用临时表一样可以保存“数据前影”，起到类似oracle的undo表空间的功能， 能采用临时表提高并发性能的，不要用nolock 。
9、聚集索引没有建在表的顺序字段上，该表容易发生页分裂 比如订单表，有订单编号orderid，也有客户编号contactid，那么聚集索引应该加在哪个字段上呢?对于该表，订单编号是顺序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，这样不容易经常产生页分裂。
然而，由于大多数查询都是根据客户编号来查的，因此，将聚集索引加在contactid上才有意义。
而contactid对于订单表而言，并非顺序字段。
比如“张三”的“contactid”是001，那么“张三”的订单信息必须都放在这张表的第一个数据页上，如果今天“张三”新下了一个订单，那该订单信息不能放在表的最后一页，而是第一页!如果第一页放满了呢?很抱歉，该表所有数据都要往后移动为这条记录腾地方。
SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引实际上是对表按照聚集索引字段的顺序进行了排序，相当于oracle的索引组织表。
SQL Server的聚集索引就是表本身的一种组织形式，所以它的效率是非常高的。
也正因为此，插入一条记录，它的位置不是随便放的，而是要按照顺序放在该放的数据页，如果那个数据页没有空间了，就引起了页分裂。
所以很显然，聚集索引没有建在表的顺序字段上，该表容易发生页分裂。
曾经碰到过一个情况，一位哥们的某张表重建索引后，插入的效率大幅下降了。
估计情况大概是这样的。
该表的聚集索引可能没有建在表的顺序字段上，该表经常被归档，所以该表的数据是以一种稀疏状态存在的。
比如张三下过20张订单，而最近3个月的订单只有5张，归档策略是保留3个月数据，那么张三过去的15张订单已经被归档，留下15个空位，可以在insert发生时重新被利用。
在这种情况下由于有空位可以利用，就不会发生页分裂。
但是查询性能会比较低，因为查询时必须扫描那些没有数据的空位。
重建聚集索引后情况改变了，因为重建聚集索引就是把表中的数据重新排列一遍，原来的空位没有了，而页的填充率又很高，插入数据经常要发生页分裂，所以性能大幅下降。
对于聚集索引没有建在顺序字段上的表，是否要给与比较低的页填充率?是否要避免重建聚集索引?是一个值得考虑的问题! 10、加nolock后查询经常发生页分裂的表，容易产生跳读或重复读 加nolock后可以在“插、删、改”的同时进行查询，但是由于同时发生“插、删、改”，在某些情况下，一旦该数据页满了，那么页分裂不可避免，而此时nolock的查询正在发生，比如在第100页已经读过的记录，可能会因为页分裂而分到第101页，这有可能使得nolock查询在读101页时重复读到该条数据，产生“重复读”。
同理，如果在100页上的数据还没被读到就分到99页去了，那nolock查询有可能会漏过该记录，产生“跳读”。
上面提到的哥们，在加了nolock后一些操作出现报错，估计有可能因为nolock查询产生了重复读，2条相同的记录去插入别的表，当然会发生主键冲突。
11、使用like进行模糊查询时应注意 有的时候会需要进行一些模糊查询比如 Select * from contact where username like ‘%yue%’ 关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%， 12、数据类型的隐式转换对查询效率的影响 sql server2000的数据库，我们的程序在提交sql语句的时候，没有使用强类型提交这个字段的值，由sql server 2000自动转换数据类型，会导致传入的参数与主键字段类型不一致，这个时候sql server 2000可能就会使用全表扫描。
Sql2005上没有发现这种问题，但是还是应该注意一下。
13、SQL Server 表连接的三种方式 (1) Merge Join (2) Nested Loop Join (3) Hash Join SQL Server 2000只有一种join方式——Nested Loop Join，如果A结果集较小，那就默认作为外表，A中每条记录都要去B中扫描一遍，实际扫过的行数相当于A结果集行数x B结果集行数。
所以如果两个结果集都很大，那Join的结果很糟糕。
SQL Server 2005新增了Merge Join，如果A表和B表的连接字段正好是聚集索引所在字段，那么表的顺序已经排好，只要两边拼上去就行了，这种join的开销相当于A表的结果集行数加上B表的结果集行数，一个是加，一个是乘，可见merge join 的效果要比Nested Loop Join好多了。