3.2　高效的查询选择

　　从以上查询优化的3个阶段不难看出，设计出物理I/O和逻辑I/O最少的方案并掌握好处理器时间和I/O时间的平衡，是高效查询设计的主要目标。也就是说，希望设计出这样的查询：充分利用索引、磁盘读写最少、最高效地利用了内存和CPU资源。

　　以下建议是从SQL Server优化器的优化策略中总结出来的，对于设计高效的查询是很有帮助的。

　　（1）如果有独特的索引，那么带有“=”操作符的WHERE子句性能最好，其次是封闭的区间（范围），再其次是开放的区间。

　　（2）从数据库访问的角度看，含有不连续连接词（OR和IN）的WHERE子句一般来说性能不会太好。所以，优化器可能会采用R策略，这种策略会生成1个工作表，其中含有每个可能匹配的执行的标识符，优化器把这些行标志符（页号和行号）看做是指向1个表中匹 配的行的“动态索引”。优化器只需扫描工作表，取出每一个行标志符，再从数据表中取得相应的行，所以R策略的代价是生成工作表。

　　（3）包含NOT、<>、或!　=的WHERE子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。

　　（4）限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式生成索引选择。例如：

　　paycheck * 12>36000 or subSTring(lAStname,1,1)="L"

　　如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改写上面的条件表达式为：

　　paycheck<36000/12 or lastname like "L%"

　　（5）WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为储备过程输入参数的变量。

　　（6）如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。所以应该注意RAM中或磁盘上的数据库tempDB的大小（除了SELECT INTO语句）。另外，如果这些类型的操作是很常见的，那么把tempdb放在RAM中对于提高性能是很有好处的。

　　4　性能优化的其他考虑

　　上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选项也不同程度上影响了SQL Server的性能

　　影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。