通常，在做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/
