我在AdventureWorks2012数据库中运行此查询:
SELECT
s.SalesOrderID,
d.CarrierTrackingNumber,
d.ProductID,
d.OrderQty
FROM Sales.SalesOrderHeader s
JOIN Sales.SalesOrderDetail d
ON s.SalesOrderID = d.SalesOrderID
WHERE s.CustomerID = 11077
如果我查看估计的执行计划,我会看到以下内容:
初始索引搜索(右上角)使用 IX_SalesOrderHeader_CustomerID 索引并搜索文字 11077。它估计有 2.6192 行。
如果我使用DBCC SHOW_STATISTICS ('Sales.SalesOrderHeader', 'IX_SalesOrderHeader_CustomerID') WITH HISTOGRAM
,则表明值 11077 在两个采样键 11019 和 11091 之间。
11019 和 11091 之间的平均不同行数为 2.619718,或四舍五入为 2.61972,这是为索引查找显示的估计行的值。
我不明白的部分是聚集索引查找 SalesOrderDetail 表的估计行数。
如果我运行DBCC SHOW_STATISTICS ('Sales.SalesOrderDetail', 'PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID')
:
所以 SalesOrderID(我加入)的密度是 3.178134E-05。这意味着 1/3.178134E-05 (31465) 等于 SalesOrderDetail 表中唯一 SalesOrderID 值的数量。
如果 SalesOrderDetail 中有 31465 个唯一的 SalesOrderID,则在均匀分布的情况下,每个 SalesOrderID 的平均行数为 121317(总行数)除以 31465。平均值为 3.85561
因此,如果估计要循环的行数是 2.61972,并且要在 3.85561 中返回平均值,我认为估计的行数将是 2.61972 * 3.85561 = 10.10062。
但估计的行数是 11.4867。
我认为我对第二个估计的理解是不正确的,不同的数字似乎表明了这一点。我错过了什么?
使用 SQL Server 2012 基数估计器,连接的选择性驱动嵌套循环连接内侧的估计行数,而不是相反。
11.4867 数字是通过将连接输出的计算估计基数 (30.0919) 除以迭代次数 (2.61972)得出的(用于在 showplan 中显示)。使用单精度浮点运算的结果是11.4867。
它真的是那么简单。请注意,(逻辑)连接选择性与物理连接运算符的选择无关。无论最终是使用嵌套循环、哈希还是合并连接物理运算符执行连接,都保持不变。
在 SQL Server 2012 及更早版本中,连接选择性(作为一个整体)是使用每个表中的直方图估计的
SalesOrderID
(针对每个直方图步骤计算,在必要时使用线性插值在步骤边界对齐之后)。SalesOrderID
与表格关联的直方图SalesOrderHeader
也针对独立CustomerID
滤波器的缩放效果进行了调整。这并不是说问题中提出的替代计算存在任何根本“错误”;它只是做了一组不同的假设。对于给定的逻辑操作序列,总会有不同的方法来计算或组合估计。不能普遍保证应用于相同数据的不同统计方法会产生相同的答案,或者一种方法总是优于另一种方法。应用不同统计方法导致的不一致甚至会出现在单个最终执行计划中,尽管它们很少被注意到。
作为旁注,SQL Server 2014 基数估计器采用不同的方法来组合独立过滤器调整的直方图信息(“粗略对齐”),这导致该查询的最终估计为10.1006行:
这恰好与问题中的计算结果相同,尽管详细推理不同(即它不是基于假设的嵌套循环实现)。