为什么 MSSQL 在执行计划中选择扫描？

Question

这是我的查询（这是一个 Microsoft Axapta 查询）：

(@P1 bigint)
SELECT TOP 1 T1.JOURNALNUM,T1.LINENUM,T1.ACCOUNTTYPE,T1.COMPANY,T1.TXT,
T1.AMOUNTCURDEBIT,T1.CURRENCYCODE,T1.EXCHRATE,T1.TAXGROUP,
T1.CASHDISCPERCENT,T1.QTY,T1.BANKNEGINSTRECIPIENTNAME,
-- *Snipped lots of columns in T1* --
T1.MODIFIEDDATETIME,T1.RECVERSION,T1.PARTITION,T1.RECID 
FROM LEDGERJOURNALTRANS T1 
WHERE (((PARTITION=123123123) AND (DATAAREAID=N'test')) AND (REVRECID=@P1))

当前执行计划：

当前计划

实际上，表上有一个合适的索引。

索引列：(PARTITION,DATAAREAID,REVRECID)

碎片化：

我试过索引力。这个执行计划（索引查找+键查找）比执行计划（索引扫描）要快：

力指数计划

我试图：

• 更新统计

• 更改了列顺序，例如 (REVRECID,PARTITION,DATAAREAID)

MSSQL 为什么选择聚集索引？

Answer 1

估计，选择了大量的列和谓词下推

查询的估计没有考虑到扫描的剩余谓词比从聚集索引中获取所有这些额外列的搜索 + 键查找的成本更高。这导致选择聚集索引扫描 + 残差谓词而不是索引查找。

我的版本是 Microsoft SQL Server 2016 (RTM-GDR)

这些对谓词下推的估计在SQL Server 2016 SP1中有所改进

更新以改进对 SQL Server 2016 中涉及剩余谓词下推的查询执行计划的诊断

为了改进对“症状”部分中描述的方案的诊断，SQL Server 2016 Service Pack 1 (SP1) 引入了一个新的显示计划 XML 属性，估计读取的行数。此属性提供在应用残差谓词之前运算符将读取的估计行数。此更新是对 KB 3107397 的补充。

这将添加 EstimatedRowsRead=""到查询计划 XML，在您的情况下，如果选择扫描，这将接近或匹配残差谓词。

这应该可以解决您的问题

残差谓词示例

读取 1.2M 行返回 0

索引扫描查询估计总成本

EstimatedTotalSubtreeCost="0.00449281">

索引查找查询估计总成本

EstimatedTotalSubtreeCost="0.00672858">

由于不考虑残差谓词，这高于索引扫描估计，这就是选择性能较差的计划的原因。

主要解决方案

主要的解决方案是升级到至少 SP1 以添加：

更新以改进对 SQL Server 2016 中涉及剩余谓词下推的查询执行计划的诊断

你应该更快，更频繁地打补丁，因为SP2 CU6是出于为2019年3月19，这将是一个更好的选择。

另一个旁注，SQL Server 2016 的SP1添加了许多附加功能，例如内存中 OLTP、压缩、列存储索引等。

其他可能值得也可能不值得一提的解决方法

• 如果不需要，则选择较少的列
• 将所有这些列添加到 NC 索引的包含列中
• 您可以尝试使用（也许）禁用行目标OPTION(QUERYTRACEON 4138)
• 使用WITH(INDEX))提示

与 SQL Server 2016 SP1 的比较

运行与您类似的查询时，强制在 SQL2016 SP1 版本上使用聚集索引：

估计的子树成本要高得多。

EstimatedTotalSubtreeCost="93.6951"

聚集索引扫描的估计子树成本在哪里

<RelOp AvgRowSize="4788" EstimateCPU="1.36996" EstimateIO="185.267" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row" EstimateRows="1" LogicalOp="Clustered Index Scan" NodeId="1" Parallel="false" PhysicalOp="Clustered Index Scan" EstimatedTotalSubtreeCost="0.00448209" TableCardinality="1245280">

低

EstimatedTotalSubtreeCost="0.00448209"

主要区别在于

EstimatedRowsRead="1000000"

在应用SP1的 SQL 2016 上执行查询时显示。

当使用指定的 NC 索引进行测试时

CREATE INDEX IX_PARTITION_DATAAREAID_REVRECID
ON dbo.LEDGERJOURNALTRANS(PARTITION,DATAAREAID,REVRECID);

<RelOp AvgRowSize="980" EstimateCPU="0.0001581" EstimateIO="0.003125" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row" EstimateRows="1" LogicalOp="Clustered Index Seek" NodeId="4" Parallel="false" PhysicalOp="Clustered Index Seek" EstimatedTotalSubtreeCost="0.0032831" TableCardinality="1000000">

索引搜索的 EstimatedTotalSubtreeCost（不是整个计划的总成本）也很低：

 EstimatedTotalSubtreeCost="0.0032831

并且我的测试查询的总估计子树成本与您的非常接近

EstimatedTotalSubtreeCost="0.00657048">