常用SQL书写技巧

一般情况下，sqlserver 会对表的连接作出自动优化。例如：

select name,no from A

join B on A. id=B.id

join C on C.id=A.id

where name='wang'

尽管A表在From中先列出，然后才是B,最后才是C。但sql server可能会首先使用c表。它的选择原则是相对于该查询限制为单行或少数几行，就可以减少在其他表中查找的总数据量。绝大多数情况下，sql server 会作出最优的选择，但如果你发觉某个复杂的联结查询速度比预计的要慢，就可以使用SET FORCEPLAN语句强制sql server按照表出现顺序使用表。如上例加上：SET FORCEPLAN ON…….SET FORCEPLAN OFF 表的执行顺序将会按照你所写的顺序执行。在查询分析器中查看2种执行效率，从而选择表的连接顺序。SET FORCEPLAN的缺点是只能在存储过程中使用。

小结：

 聚集索引比较宝贵，应该用在查询频率最高的地方；

 在数据为“既不是绝大多数相同，也不是极少数相同”状态时，

最能发挥聚集索引的潜力；

 复合索引的设置和使用要注意保持顺序一致；

 条件子句的表达式最好符合SARG规范，是可利用索引的；

 任何对列的操作都导致全表扫描，如数据库函数、计算表达式等，

查询时应尽可能将操作移至等号的某一边；

 要注意含有null值时，是不能充分利用索引的；

 exist, in、or等子句常会使索引失效；

如果不产生大量重复值，可以考虑把子句拆开，再用union拼合；

 排序时应充分利用带索引的字段；

 尽可能早，快的过滤掉无用的数据，只将必须的数据带到后续的操作中去

从前面讲叙的内容可以看出，SQL语句优化的实质就是在结果正确的前提下，用分析优化器可以识别的SARG规范语句，充份利用索引，减少数据的I/O次数，尽量避免全表扫描的发生。

以上内容有些是指导性的理论原则，有些是实际摸索的经验，大家在使用时应灵活处理，根据实际情况，选择合适的方法。本文中列举的实验数据仅作比对用，不具备普遍意义。大家在实际项目中，应充分利用性能监测和分析工具（如SQLSERVER带的相关工具）来检验自己的优化效果。

此外，还有很重要的一点要提醒大家，同样复杂的数据操作，在SQLSERVER数据库级别完成的代价要远远小于在应用端用程序代码完成的代价，所以建议大家全面，深入的学习SQL语法中重要关键字的应用，如：Group By ，Having等，尽量把数据操作任务放在数据库系统中完成 。数据库应用系统的性能优化是一个复杂的过程，上述这些只是在SQL语句层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计等等，这些将在以后的文章中详细论述