SQL优化：优化的最佳实践

SQL Server优化查询性能的最佳实践

1、在select查询中，只返回需要的列。查询中存在的列越少，则使用的IO和网络带宽就会越少。

2、在减少列的同时，也要考虑一下减少行。使用where子句来减少查询返回的行，不要让应用程序在只需显示前10行时，却返回10000行。

3、减少join次数。连接到单个查询中的每个表都会增加额外的开销。虽然具体join多少个表会收到数据库设计、容量大小以及用于关联查询的列的影响，但是短小查询有短小查询的好处。所以如果存储过程中有一个执行很长时间的非常大的查询，那么可以把这个查询分解为几个更小的中间结果，这通常会显著加快生成结果集的速度。

另外，减少join次数会降低sql的复杂程度，使得优化器生成更好的执行计划。

 

4、只在需要有序结果时，采用order by。大结果集的排序操作会导致额外开销。如果排序不是必须的那就不要排序。

5、避免在from、where、having子句中隐式数据类型的转换。当谓词中底层数据类型不匹配就会发生隐式数据类型转换，并且是由SQL Server自动转换的。比如，java应用程序发送unicode文本到非unicode列，对于每秒处理数百个事务的程序来说，隐式转换会增加处理时间。另外，隐式数据类型的转换可能会导致不能引用索引，导致查询性能下降。

6、如果唯一行不是必须的，那么就不要用distinct、union（而是用union all）。

 

7、当在游标和基本集合的方法之间进行选择时，最好选择集合方法。如果必须用游标，那么使用完后一定要尽快关闭和释放。

8、存储过程可以提升查询执行的稳定性（重用既有的查询计划），所以可以把一个查询封装到存储过程中，这样可能会提升性能。

9、应该避免使用嵌套视图。如果在创建视图时引用了其他视图，而这个创建的视图所引用的对象，在被调用的视图中已经被引用过了，那么由于查询的复杂性，这个重复和重叠经常会造成未优化的查询计划。

 

10、在复杂的数据库驱动的应用程序中，在某些情况下使用查询提示是必要的。不过，当底层的数据量、分布情况发生变化时，查询提示可能会覆盖SQL Server的决策处理，误导SQL Server做出最佳计划。

11、在开发数据库中，将有代表性的数据集填充到表中是非常重要的。也就是说应该把与实际生产环境中相当数量的有代表性的行填充到表中，不要在开发数据库内使用没有代表性的数据。SQL Server的性能非常依赖索引和统计信息，并且会基于表内实际的值做出决策。如果测试数据不是有代表性的较真实的数据，那么生产环境中的查询效果与测试中的效果会差异很大。