考虑以下人为但简单的查询:
SELECT ID , CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM X_OTHER_TABLE) ELSE (SELECT TOP 1 ID FROM X_OTHER_TABLE_2) END AS ID2 FROM X_HEAP;
我希望此查询的最终行估计等于X_HEAP表中的行数。无论我在子查询中做什么,对行估计都无关紧要,因为它无法过滤掉任何行。但是,在 SQL Server 2016 上,由于子查询,我看到行估计减少到 1:
X_HEAP
为什么会这样?我能做些什么呢?
使用正确的语法很容易重现此问题。这是一组可以执行此操作的表定义:
CREATE TABLE dbo.X_HEAP (ID INT NOT NULL) CREATE TABLE dbo.X_OTHER_TABLE (ID INT NOT NULL); CREATE TABLE dbo.X_OTHER_TABLE_2 (ID INT NOT NULL); INSERT INTO dbo.X_HEAP WITH (TABLOCK) SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) FROM master..spt_values; CREATE STATISTICS X_HEAP__ID ON X_HEAP (ID) WITH FULLSCAN;
dbfiddle链接。
在以下情况下,此基数估计 (CE) 问题会出现:
注意:用于确定选择性的特定计算器并不重要。
CE 将外连接的选择性计算为以下各项之和:
外连接和内连接之间的唯一区别是外连接还返回与连接谓词不匹配的行。反连接恰好提供了这种差异。内连接和反连接的基数估计比直接外连接更容易。
连接选择性估计过程非常简单:
SPT
谓词是整个事物,包括任何否定IsFalseOrNull成分。
IsFalseOrNull
内部连接选择性:=1 - SPT
1 - SPT
反连接选择性:=SPT
反连接表示将“通过”连接的行。内连接表示不会“通过”的行。请注意,“通过”表示流过连接的行,根本不运行内侧。强调一下:连接将返回所有行,区别在于在出现之前运行连接内侧的行和不运行的行。
显然,添加到应始终提供 1 的总选择性,这意味着所有行都由连接返回,正如预期的那样。1 - SPTSPT
实际上,上述计算的工作原理与对除 1 之外的所有值的描述完全相同。SPT
当= 1 时,内连接和反连接选择性都估计为零,从而产生一行的基数估计(对于整个连接)。据我所知,这是无意的,应该报告为错误。SPT
由于单独的 CE 限制,此错误比人们想象的更可能出现。当CASE表达式使用EXISTS子句时会出现这种情况(这很常见)。例如,问题中的以下修改查询不会遇到意外的基数估计:
CASE
EXISTS
-- This is fine SELECT CASE WHEN XH.ID = 1 THEN (SELECT TOP (1) XOT.ID FROM dbo.X_OTHER_TABLE AS XOT) END FROM dbo.X_HEAP AS XH;
引入一个小EXISTS问题确实会导致问题浮出水面:
-- This is not fine SELECT CASE WHEN EXISTS (SELECT 1 WHERE XH.ID = 1) THEN (SELECT TOP (1) XOT.ID FROM dbo.X_OTHER_TABLE AS XOT) END FROM dbo.X_HEAP AS XH;
UsingEXISTS在执行计划中引入了一个半连接(突出显示):
半连接的估计很好。问题是 CE 将关联的探针列视为一个简单的投影,固定选择性为 1:
Semijoin with probe column treated as a Project. Selectivity of probe column = 1
无论条款的内容如何,这都会自动满足此 CE 问题出现所需的条件之一EXISTS。
这绝对看起来像是无意的行为。确实,基数估计不需要在计划的每一步都保持一致,但这是一个相对简单的查询计划,最终的基数估计与查询所做的不一致。如此低的基数估计可能导致更复杂的计划中下游其他表的连接类型和访问方法选择不佳。
通过反复试验,我们可以提出一些未出现问题的类似查询:
SELECT ID , CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) ELSE (SELECT -1) END AS ID2 FROM dbo.X_HEAP; SELECT ID , CASE WHEN ID < 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) WHEN ID >= 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) END AS ID2 FROM dbo.X_HEAP;
我们还可以提出更多出现问题的查询:
SELECT ID , CASE WHEN ID < 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) WHEN ID >= 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) ELSE (SELECT TOP 1 ID FROM X_OTHER_TABLE) END AS ID2 FROM dbo.X_HEAP; SELECT ID , CASE WHEN ID = 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) ELSE (SELECT -1) END AS ID2 FROM dbo.X_HEAP; SELECT ID , CASE WHEN ID = 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) ELSE (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) END AS ID2 FROM dbo.X_HEAP;
似乎有一种模式:如果 中有一个CASE不期望执行的表达式,并且结果表达式是针对表的子查询,则行估计在该表达式之后下降到 1。
如果我针对具有聚集索引的表编写查询,则规则会有所改变。我们可以使用相同的数据:
CREATE TABLE dbo.X_CI (ID INT NOT NULL, PRIMARY KEY (ID)) INSERT INTO dbo.X_CI WITH (TABLOCK) SELECT * FROM dbo.X_HEAP; UPDATE STATISTICS X_CI WITH FULLSCAN;
此查询的最终估计值为 1000 行:
SELECT ID , CASE WHEN ID = 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) ELSE (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) END FROM dbo.X_CI;
但是这个查询有 1 行的最终估计:
SELECT ID , CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) ELSE (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) END FROM dbo.X_CI;
为了进一步深入研究,我们可以使用未记录的跟踪标志 2363来获取有关查询优化器如何执行选择性计算的信息。我发现将该跟踪标志与未记录的跟踪标志 8606配对很有帮助。TF 2363 似乎为简化树和项目规范化后的树提供了选择性计算。启用两个跟踪标志可以明确哪些计算适用于哪棵树。
让我们尝试一下问题中发布的原始查询:
SELECT ID , CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM X_OTHER_TABLE) ELSE (SELECT TOP 1 ID FROM X_OTHER_TABLE_2) END AS ID2 FROM X_HEAP OPTION (QUERYTRACEON 3604, QUERYTRACEON 2363, QUERYTRACEON 8606);
这是我认为与一些评论相关的输出部分的一部分:
Plan for computation: CSelCalcColumnInInterval -- this is the type of calculator used Column: QCOL: [SE_DB].[dbo].[X_HEAP].ID -- this is the column used for the calculation Pass-through selectivity: 0 -- all rows are expected to have a true value for the case expression Stats collection generated: CStCollOuterJoin(ID=8, CARD=1000 x_jtLeftOuter) -- the row estimate after the join will still be 1000 CStCollBaseTable(ID=1, CARD=1000 TBL: X_HEAP) CStCollBaseTable(ID=2, CARD=1 TBL: X_OTHER_TABLE) ... Plan for computation: CSelCalcColumnInInterval Column: QCOL: [SE_DB].[dbo].[X_HEAP].ID Pass-through selectivity: 1 -- no rows are expected to have a true value for the case expression Stats collection generated: CStCollOuterJoin(ID=9, CARD=1 x_jtLeftOuter) -- the row estimate after the join will still be 1 CStCollOuterJoin(ID=8, CARD=1000 x_jtLeftOuter) -- here is the row estimate after the previous join CStCollBaseTable(ID=1, CARD=1000 TBL: X_HEAP) CStCollBaseTable(ID=2, CARD=1 TBL: X_OTHER_TABLE) CStCollBaseTable(ID=3, CARD=1 TBL: X_OTHER_TABLE_2)
现在让我们尝试一个没有问题的类似查询。我将使用这个:
SELECT ID , CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) ELSE (SELECT -1) END AS ID2 FROM dbo.X_HEAP OPTION (QUERYTRACEON 3604, QUERYTRACEON 2363, QUERYTRACEON 8606);
最后调试输出:
Plan for computation: CSelCalcColumnInInterval Column: QCOL: [SE_DB].[dbo].[X_HEAP].ID Pass-through selectivity: 1 Stats collection generated: CStCollOuterJoin(ID=9, CARD=1000 x_jtLeftOuter) CStCollOuterJoin(ID=8, CARD=1000 x_jtLeftOuter) CStCollBaseTable(ID=1, CARD=1000 TBL: dbo.X_HEAP) CStCollBaseTable(ID=2, CARD=1 TBL: dbo.X_OTHER_TABLE) CStCollConstTable(ID=4, CARD=1) -- this is different than before because we select a constant instead of from a table
让我们尝试另一个存在错误行估计的查询:
SELECT ID , CASE WHEN ID < 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) WHEN ID >= 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) ELSE (SELECT TOP 1 ID FROM X_OTHER_TABLE) END AS ID2 FROM dbo.X_HEAP OPTION (QUERYTRACEON 3604, QUERYTRACEON 2363, QUERYTRACEON 8606);
最后,基数估计下降到 1 行,再次在通过选择性 = 1 之后。基数估计在选择性为 0.501 和 0.499 后保留。
Plan for computation: CSelCalcColumnInInterval Column: QCOL: [SE_DB].[dbo].[X_HEAP].ID Pass-through selectivity: 0.501 ... Plan for computation: CSelCalcColumnInInterval Column: QCOL: [SE_DB].[dbo].[X_HEAP].ID Pass-through selectivity: 0.499 ... Plan for computation: CSelCalcColumnInInterval Column: QCOL: [SE_DB].[dbo].[X_HEAP].ID Pass-through selectivity: 1 Stats collection generated: CStCollOuterJoin(ID=12, CARD=1 x_jtLeftOuter) -- this is associated with the ELSE expression CStCollOuterJoin(ID=11, CARD=1000 x_jtLeftOuter) CStCollOuterJoin(ID=10, CARD=1000 x_jtLeftOuter) CStCollBaseTable(ID=1, CARD=1000 TBL: dbo.X_HEAP) CStCollBaseTable(ID=2, CARD=1 TBL: dbo.X_OTHER_TABLE) CStCollBaseTable(ID=3, CARD=1 TBL: dbo.X_OTHER_TABLE_2) CStCollBaseTable(ID=4, CARD=1 TBL: X_OTHER_TABLE)
让我们再次切换到另一个没有问题的类似查询。我将使用这个:
SELECT ID , CASE WHEN ID < 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) WHEN ID >= 500 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) END AS ID2 FROM dbo.X_HEAP OPTION (QUERYTRACEON 3604, QUERYTRACEON 2363, QUERYTRACEON 8606);
在调试输出中,从来没有一个步骤的传递选择性为 1。基数估计保持在 1000 行。
Plan for computation: CSelCalcColumnInInterval Column: QCOL: [SE_DB].[dbo].[X_HEAP].ID Pass-through selectivity: 0.499 Stats collection generated: CStCollOuterJoin(ID=9, CARD=1000 x_jtLeftOuter) CStCollOuterJoin(ID=8, CARD=1000 x_jtLeftOuter) CStCollBaseTable(ID=1, CARD=1000 TBL: dbo.X_HEAP) CStCollBaseTable(ID=2, CARD=1 TBL: dbo.X_OTHER_TABLE) CStCollBaseTable(ID=3, CARD=1 TBL: dbo.X_OTHER_TABLE_2) End selectivity computation
当查询涉及具有聚集索引的表时,查询会怎样?考虑以下带有行估计问题的查询:
SELECT ID , CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) ELSE (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) END FROM dbo.X_CI OPTION (QUERYTRACEON 3604, QUERYTRACEON 2363, QUERYTRACEON 8606);
调试输出的结尾与我们已经看到的类似:
Plan for computation: CSelCalcColumnInInterval Column: QCOL: [SE_DB].[dbo].[X_CI].ID Pass-through selectivity: 1 Stats collection generated: CStCollOuterJoin(ID=9, CARD=1 x_jtLeftOuter) CStCollOuterJoin(ID=8, CARD=1000 x_jtLeftOuter) CStCollBaseTable(ID=1, CARD=1000 TBL: dbo.X_CI) CStCollBaseTable(ID=2, CARD=1 TBL: dbo.X_OTHER_TABLE) CStCollBaseTable(ID=3, CARD=1 TBL: dbo.X_OTHER_TABLE_2)
但是,对没有问题的 CI 的查询具有不同的输出。使用此查询:
SELECT ID , CASE WHEN ID = 0 THEN (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE_2) ELSE (SELECT TOP 1 ID FROM dbo.X_OTHER_TABLE) END FROM dbo.X_CI OPTION (QUERYTRACEON 3604, QUERYTRACEON 2363, QUERYTRACEON 8606);
结果导致使用不同的计算器。CSelCalcColumnInInterval不再出现:
CSelCalcColumnInInterval
Plan for computation: CSelCalcFixedFilter (0.559) Pass-through selectivity: 0.559 Stats collection generated: CStCollOuterJoin(ID=8, CARD=1000 x_jtLeftOuter) CStCollBaseTable(ID=1, CARD=1000 TBL: dbo.X_CI) CStCollBaseTable(ID=2, CARD=1 TBL: dbo.X_OTHER_TABLE_2) ... Plan for computation: CSelCalcUniqueKeyFilter Pass-through selectivity: 0.001 Stats collection generated: CStCollOuterJoin(ID=9, CARD=1000 x_jtLeftOuter) CStCollOuterJoin(ID=8, CARD=1000 x_jtLeftOuter) CStCollBaseTable(ID=1, CARD=1000 TBL: dbo.X_CI) CStCollBaseTable(ID=2, CARD=1 TBL: dbo.X_OTHER_TABLE_2) CStCollBaseTable(ID=3, CARD=1 TBL: dbo.X_OTHER_TABLE)
总之,在以下条件下,我们似乎在子查询之后得到了错误的行估计:
CStCollBaseTable
也许在这些条件下,查询优化器无意中将传递选择性应用于外部表的行估计,而不是应用于嵌套循环内部完成的工作。这会将行估计值减少到 1。
我能够找到两种解决方法。APPLY使用而不是子查询时,我无法重现该问题。跟踪标志 2363 的输出与APPLY. 这是重写问题中原始查询的一种方法:
APPLY
SELECT h.ID , a.ID2 FROM X_HEAP h OUTER APPLY ( SELECT CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM X_OTHER_TABLE) ELSE (SELECT TOP 1 ID FROM X_OTHER_TABLE_2) END ) a(ID2);
旧版 CE 似乎也避免了这个问题。
SELECT ID , CASE WHEN ID <> 0 THEN (SELECT TOP 1 ID FROM X_OTHER_TABLE) ELSE (SELECT TOP 1 ID FROM X_OTHER_TABLE_2) END AS ID2 FROM X_HEAP OPTION (USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION'));