游标脚本性能问题详解之案例实践篇(1)(3)

三、分析本案例中两种游标的执行计划

现在我们回到需要研究的脚本，在这里，语句是一样的，不同的只是游标的类型。不同的执行时间说明很可能这个语句使用了不同的执行计划。现在问题变成了，同样语句使用了不同的执行计划，得到了不同的执行时间。我们首先从”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 '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 '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使用了不同的访问方式

接下来我们分析两个脚本的执行计划：

1. dynamic游标对应的不理想的执行计划中，SQL Server选择了索引扫描(index scan)及索引S_AUDIT_ITEM_M4来查阅S_AUDIT_ITEM表。因此我们会在这里看到大量的IO。

这个索引扫描实际上访问了整张表的数据。

2.而fast forward only游标对应的理想的执行计划中，SQL Server选择的是索引查找(index seek)及索引S_AUDIT_ITEM_M3来查阅S_AUDIT_ITEM表。所以我们只看到3个逻辑读。索引S_AUDIT_ITEM_M3包含4个列，第一个列是RECORD_ID。另外，在语句中，有WHERE条件T1.RECORD_ID=@P2