通往性能优化的天堂-地狱 JOIN方法说明

核心提示： 前面三个执行步骤a)、b)、c)跟1.4中一样，有一点需要注意的是，通往性能优化的天堂-地狱 JOIN方法说明(4)，步骤c)是执行Index Seek操作，它跟Clustered Index Seek有区别，在这个过程中运用tableB.col2=?这个条件，同样避免一个额外的Filte

前面三个执行步骤a)、b)、c)跟1.4中一样，有一点需要注意的是，步骤c)是执行Index Seek操作，它跟Clustered Index Seek有区别。聚集索引的根节点是每一条实际数据记录，而非聚集索引的根节点是对聚集索引根结点键值的引用（如果表存在聚集索引），或者是对实际数据记录rowid的引用（指没有聚集索引的表，这种表称为heap表）。Clustered Index Seek执行之后，实际的物理数据记录已经被加载到内存中，而Index Seek操作之后，并没有加载实际的物理数据记录，而只是非聚集索引的根结点数据，其中只包含了索引字段数据以及引用的聚集索引键值或者rowid。SQL Server在这个步骤中使用非聚集索引根结点数据中的索引字段值，与outer input中的记录（rowA）关联字段进行匹配，判断是否是符合条件的结果，如果是，则将非聚集索引根结点数据结构保存到nested loop操作的输出数据结构中，并且会创建一个书签（Bookmark），指示在必要的时候需要根据这个书签去获取引用的数据。

d) 执行Bookmark Lookup操作。nested loop操作的输出是一个内存数据结构，在从这个内存数据结构中整理出整个查询语句的输出结果集之前，需要处理前面的书签引用问题，Bookmark Lookup操作就是根据书签中引用的聚集索引键值或者rowid获取具体记录数据。

e) Filter过滤操作。回顾前面几个操作，在执行nested loop时只是使用非聚集索引的索引字段（tableB.col1）跟outer input的关联字段进行匹配，到目前为止还没有使用tableB.col2=?这个条件，这个操作就是使用tableB.col2=?对Bookmark Lookup的输出进行过滤。

看的仔细的人到这里后可能会有几个疑问，1. tableA.col2=?怎么没有一个Filter操作？2. 在1.4中为什么没有出现Filter操作？解释如下：1. 在tableA上面执行的是Table Scan操作，是直接对每条实际数据进行扫描，在这个扫描过程中可以使用tableA.col2=?这个条件进行过滤，避免一个额外的Filter操作。鼠标移动到Table Scan操作上，从提示信息的参数（Argument）里面可以看到tableA.col2=?的条件已经被运用上了。2. 前面说过，聚集索引的根节点是实际数据记录，执行Clustered Index Seek的时候，最终也是扫描到了实际数据记录，在这个过程中运用tableB.col2=?这个条件，同样避免一个额外的Filter操作。这就是1.4中没有Filter操作的原因。