这里打印出来了语句中访问过的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低的那个执行计划就是相对优化的。
三、分析本案例中两种游标的执行计划
现在我们回到需要研究的脚本，在这里，语句是一样的，不同的只是游标的类型。不同的执行时间说明很可能这个语句使用了不同的执行计划。现在问题变成了，同样语句使用了不同的执行计划，得到了不同的执行时间。我们首先从”set statistics io on” 的结果入手：
1.左边使用dynamic游标有大量的逻辑读，情况如下：
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'S_AUDIT_ITEM'. Scan count 1, logical reads 9770695, physical reads 0, read-ahead reads 1, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
2．而右边使用fast forward only游标只有三次逻辑读，情况为：
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'S_AUDIT_ITEM'. 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 S_AUDIT_ITEM上SQL Server使用了不同的访问方式
