当前位置：首页 > article >正文

SQL Server 查询语句中，对索引列做CONVERT的影响

article 2025/3/14 4:24:50

通常，在做SQL Server查询语句优化的时候，如果发现语句对索引列做了函数计算，都会建议改写，将计算的逻辑转移到筛选条件列上。但这种对索引列的计算，有时却会带来一些额外的好处。请看以下的例子：

--测试数据库 adventureworks2022，兼容级别160
--创建如下的索引：
USE AdventureWorks2022
go
CREATE NONCLUSTERED INDEX IX_ModifiedDate
  ON Sales.SalesOrderDetail (ModifiedDate);
GO

--Query 原语句
DECLARE @a DATE = '2012-06-29'
SELECT Count(1)
FROM   Sales.SalesOrderDetail
WHERE  CONVERT(DATE, ModifiedDate) = @a 

--Query 改写后语句
SELECT Count(1)
FROM   Sales.SalesOrderDetail
WHERE  ModifiedDate >= @a
       AND ModifiedDate < Dateadd(day, 1, @a)
GO

语句执行后，返回值是9。查看实际的执行计划，改写前成本 4%，改写后成本 96%，为什么这样改写后执行成本反而更高了？

仔细比较一下执行计划，可以发现在index seek这个步骤，改写前后的估计值是不一样的，改写前是127，改写后变成了19934。

为什么这个改写后的预估值会变得这么大？

改写后的语句，就是遇到了所谓的本地变量（local variable）的情景，也就是在编译时，不管变量的具体值是什么，而是按照固定的估计值进行的编译，生成执行计划。

这个固定预估值的计算规则如下：

如果是等值条件，那么就是按照总行数乘以总密度。ModifiedDate列上索引的统计信息如下：表行数是121317行，ModifiedDate列的总密度为 0.0008896797，总行数乘以总密度，即 12317 * 0.0008896797 = 107.9 行

而等值的查询条件，其执行计划中的估计值，就是108。

而对于非等值条件，则按照下表做估计（Guess）：

表Sales.SalesOrderDetail一共有121317行，按照上图中，查询条件是 >= 和 < ，类似between ，于是121317 * 0.16 = 19410，得到的结果与估计值19934很接近。

这就是改写后估计值非常大的原因。

而为什么改写前的估计值比较小，更接近于实际结果呢？

比较改写前后的执行计划，会发现改写之前的语句，在生成执行计划时，用到了索引上的统计信息，所以估计的值就比较准确，而改写后就没有用到统计信息，如下图：

对于这种convert的索引列如何根据统计信息生成估计值，暂时还没有研究出来。不过试了几个不同的值，包括异常的日期值，预估的执行计划中，估计值都是相同的127。例如：

那对于本地变量的问题，可以在语句中加个recompile的提示，就可以用实际的变量值编译执行计划，自然会提高效率。

--Query 改写前
DECLARE @a DATE = '2012-06-29'
SELECT Count(1)
FROM   Sales.SalesOrderDetail
WHERE  CONVERT(DATE, ModifiedDate) = @a 

--Query 改写后
SELECT Count(1)
FROM   Sales.SalesOrderDetail
WHERE  ModifiedDate >= @a
       AND ModifiedDate < Dateadd(day, 1, @a)
option(recompile) --重编译提示
GO

如下图，加上recompile提示后，估计的行数更准确，执行成本有明显的降低。

参考链接：Yet Another Post About Local Variables In SQL Server – Darling Data (erikdarling.com)https://erikdarling.com/yet-another-post-about-local-variables/