SQLServer执行计划成本（续2）

哈希连接

哈希和合并连接都是分开处理内部源和外部源的。连接条件不能用作搜索参数。当没有为表或存在的不合适的索引明确指定搜索参数时，就要对那个表进行扫描。有可能哈希和合并连接有书签查找操作，但也未必，除非强制指定连接类型。

下面的查询明确声明一个哈希连接。连接操作里的每一个表指定了搜索条件，并且两个表都有聚集索引或覆盖索引。

SELECT m.ID, n.Value
FROM M2C m INNER HASH JOIN M2D n ON n.ID = m.ID
WHERE m.GroupID = @Group1 AND n.GroupID = @Group2

图2-19里的执行计划由每个源上的索引搜索操作加上哈希连接共计3部分组成。哈希连接的成本细节在图2-20里显示。

图2-19.哈希连接执行计划

图2-20.哈希连接成本细节


哈希和合并连接对于内部源和外部源的成本结构按照前面描述的索引搜索或表扫描操作的规则。外部源和内部源操作都在所有行参与的单个执行里处理，不象循环连接的内部源是根据外部源的每行执行一次。哈希连接组成的操作的成本结构大致按照下面的规则：

CPU Cost = ~0.017770 + ~0.00001881 per row, 1-to-1 join
        + 0.00000523 to 0.000000531 per additional row in IS

第一行适合于一对一的连接。第二行适合于外部源的每一行连接到内部源多行的情形。每行成本结构也适合由少量行的表作为外部源的情形。上面的哈希连接的总成本为以下几个的和：外部源索引搜索，内部源索引搜索和哈希连接。

合并连接

合并连接的细节在SQLServer文档和其他地方有过讨论。有两种类型的合并连接：一对多（包括一对一）和多对多合并连接。两种类型的合并连接都要求每个表里的行排序。一对多连接是更简单更有效的操作。一对多合并连接另外的要求关键是外部源的行必须在连接列上是唯一的。外部源的每一行可以连接内部源的任意多行，但内部源的每一行不能连接外部源的多行。多对多合并连接没有要求这个条件但它是更复杂的操作。

下面的查询特别指定一个合并连接，它将强迫连接排序。外部源（M2C）在列GroupID和ID上有覆盖索引。外部源的连接列是ID字段，它是主键，所以适合一对多的合并连接条件。两个表都明确指定了一个搜索参数允许外部源和内部源上执行索引搜索操作代替表扫描。两个表都有聚集索引或覆盖索引，所以不要求书签查找操作。

SELECT m.ID, n.Value
FROM M2C m INNER MERGE JOIN M2D n ON n.ID = m.ID
WHERE m.GroupID = @Group1 AND n.GroupID = @Group2

合并连接执行计划显示在图2-21里。图2-22显示了合并连接细节。注意最下面的参数（argument）条目是MERGE。该合并连接的成本结构有三部分操作组成：两个索引搜索操作（一个为外部源另一个为内部源）和合并连接操作。索引搜索操作的成本结构已经了解了。

图2-21.合并连接执行计划

图2-22.合并连接成本细节

合并连接的成本结构基本上如下：

CPU Cost = ~0.0056046 + ~0.00000446 per row, one-to-one

成本规则对于某些个案有少量的不同。对于一对多连接，内部源每增加一行的成本是：

CPU Cost 0.000002370 per additional inner source row

对于所以类型的连接，成本结构适合外部源表提供少量行而内部源表提供更多的行的情形。 

多对多合并连接

在下面的查询里，外部源的连接列是ID2，它不是主键，也没有唯一索引。即使其他表的连接列是唯一的，明确的合并连接会强制指定的连接顺序，使第一个表作为外部源。因此该查询需要多对多的合并连接。多对多合并连接执行计划显示在图2-23里，连接细节在图2-24里。

SELECT m.ID, n.Value
FROM M2C m INNER MERGE JOIN M2D n ON n.ID = m.ID2
WHERE m.GroupID = @Group1 AND n.GroupID = @Group2


图2-23.多对多合并连接执行计划

图2-24.多对多合并连接成本细节

这里的I/O成本不为0，且参数是MANY-TO-MANY MERGE。检查范围内的行的成本，发现多对多连接操作有如下的成本规则：

I/O Cost = 0.000310471 per row
CPU Cost = 0.0056000 + 0.00004908 per row, 1-1

STATISTICS IO输出结果用表WorkTable显示了前面多对多合并的两个表的作为总和的一部分的I/O。

Table 'Worktable'. Scan count 749, logical reads 1250, physical reads 0, read-ahead reads 0.  

带排序操作的合并连接

当排序索引不可用时合并连接操作可以和排序操作一起完成。图2-25a显示了内部源上索引分离需求行时的执行计划，但不是按照指定的连接条件排的序。排序操作成本细节显示在图2-25b里。排序随行数增加的CPU成本显示在图2-26里。这种模式的CPU成本推断起来略有困难。注意当成本减去0.0000785后，成本图形在重对数尺寸上是线性的。但坡度略高过1。在大于5000行的某处，排序的CPU成本改变了，但这里不去探究它。


图2-25a.带排序操作的合并连接的执行计划

图2-25b.排序操作成本细节

图2-26.排序操作随行数增加时的CPU成本


5000行以下的排序操作成本接近下面的规则。在5000和10000行之间有骤然变化。

Sort I/O Cost = 0.011261261
Sort CPU Cost ~ 0.0000785 + 0.000005 * (rows ^ 1.16)

排序的CPU成本规则是非线性的。就是说，每行的排序成本随着排序的行数增加。