二、如何比较两个不同执行计划的优劣
在继续以下内容之前，这里要介绍一些查看和比较语句执行计划的知识。通常情况下，我们从management studio中输出图形界面的执行计划进行直观的比较，查看每个表用的访问方式，使用index还是table scan，使用了哪个index，表和表之间使用的join 方式有什么不一样。但是如果是一个复杂的语句，在不同的数据库上使用了不同的执行计划，对于同样表的访问，使用了不同的index，如何比较哪种执行计划更加优化呢?比较整个语句的执行时间是一种方法，但是这个比较的结果并不准确。语句的执行时间很容易受到其他外在因素的影响：
1. 不同机器上CPU，memory和disk的性能会影响执行时间。
2. 测试的时候有没有其他人在使用同样的数据造成阻塞
3. 其他人堆数据库的使用占用了系统资源
以上这些原因都有可能影响的语句的执行时间，从而影响到我们对语句性能结果的比较。因此我们不能把语句的执行时间作为衡量语句性能的标准。
这里介绍一种比较语句cost的方法。我们对于语句cost的衡量，主要是通过比对语句总的logical reads.
我们可以通过在management studio里的query window 执行”set statistics io on” ，在当前窗口中对所有执行的语句输出信息：
- set statistics io on
- select * from dbo.test_TicketFact
- set statistics io on
执行语句两次，以消除physical reads和read-ahead reads的影响。
输出的结果如下：
- (320 row(s) affected)
- Table 'test_TicketFact'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
这里打印出来了语句中访问过的table的访问次数，总共的logical reads，physical reads等信息
这里我们需要关注的是logic reads的值，这个值实际上决定了对于IO和DISK以及内存的消耗。当语句是第一次执行，我们会看到physical reads的数字，以,而当语句第二次执行的时候，这些数据已经被读到memory里面了，因此我们会看到physical read和read-ahead reads都变为0，而logical reads的值就变成了语句所有使用的data的量。
为什么logic reads是我们需要关注的值呢?因为logic reads决定了语句要访问数据的量。如果我们的系统瓶颈在IO上，一旦语句需要访问的数据从内存里面清除，这个语句原本所有的logic reads会全部转为physical reads.因此那些大量使用logic reads就是可能导致大量physical reads的元凶。如果我们的bottleneck是CPU，这些做大量logical reads的语句同样有可能导致大量的memory 读，而读memory是需要消耗CPU资源的。因此，无论是CPU，memory还是DISK的瓶颈，那些做大量logical reads的语句都非常可能是造成问题的原因。
由以上内容，我们可以得出结论，语句的性能好坏，取决与这个语句做了多少logical reads.因此，如果同样的语句，使用了不同的执行计划，那么总的logical reads低的那个执行计划就是相对优化的。