1. 为什么使用变量时性能更慢？ #

这本质上是SQL Server查询优化器的基数估计差异导致的：

• 当你使用字符串字面量（比如'05/10/2018'）时，优化器在编译查询时就能拿到具体的日期值，它可以直接基于这个值去查询CALENDAR表的日期索引统计信息，精准预估符合条件的行数，从而生成最优的执行计划——只扫描一次日期索引就足够关联后续表。
• 但使用变量@DateFrom时，情况就不一样了：如果是在存储过程中，优化器通常会在存储过程第一次编译时生成执行计划，这时候它不知道变量的实际值，只能依赖CALENDAR表的整体统计信息来预估行数。这种预估很可能不准确，导致优化器选择了更差的执行计划——比如同时扫描主键索引和日期索引，额外的扫描操作自然拖慢了查询速度。
  另外，也有可能存在参数嗅探的反向问题：如果第一次执行存储过程时传入的变量值对应的行数极少，生成的执行计划对后续大范围内的日期查询并不适用，后续执行就会一直沿用这个低效计划。

2. 解决性能问题的方案 #

这里有几个经过验证的可行方案，你可以根据实际场景选择：

方案一：使用OPTION(RECOMPILE)强制重新编译查询 #

在你的查询末尾加上OPTION(RECOMPILE)，这样每次执行查询时，优化器都会根据变量的实际值重新生成最优执行计划。比如：

SELECT ...
FROM YourTable t
JOIN CALENDAR c ON t.calendarid = c.calendarid
WHERE c.date >= @DateFrom AND c.date <= @DateTo
OPTION(RECOMPILE);

这个方案的好处是简单直接，能确保每次都用最优计划，但会增加一点编译时间，适合查询不是高频执行的场景。

方案二：使用OPTIMIZE FOR指定变量的典型值 #

如果你的查询有一个常用的日期范围（比如每月初查询上月数据），可以用OPTIMIZE FOR让优化器基于这个典型值生成执行计划：

SELECT ...
FROM YourTable t
JOIN CALENDAR c ON t.calendarid = c.calendarid
WHERE c.date >= @DateFrom AND c.date <= @DateTo
OPTION(OPTIMIZE FOR (@DateFrom = '05/10/2018', @DateTo = '05/17/2018'));

这样即使变量值变化，执行计划也会基于你指定的典型值来生成，避免预估偏差。

方案三：强制使用日期索引 #

如果优化器总是错误地选择扫描主键索引，你可以用FORCE INDEX强制它使用日期索引：

SELECT ...
FROM YourTable t
JOIN CALENDAR c WITH (FORCE INDEX (IX_CALENDAR_Date)) ON t.calendarid = c.calendarid
WHERE c.date >= @DateFrom AND c.date <= @DateTo;

注意：这个方案要谨慎使用，因为如果未来表的数据分布变化，强制索引可能反而变成性能瓶颈，需要定期验证。

方案四：使用动态SQL（谨慎使用） #

把变量拼接成字符串字面量来执行查询，这样优化器就能像处理字面量一样生成最优计划：

DECLARE @SQL NVARCHAR(MAX);
SET @SQL = N'
SELECT ...
FROM YourTable t
JOIN CALENDAR c ON t.calendarid = c.calendarid
WHERE c.date >= ''' + CONVERT(VARCHAR, @DateFrom, 101) + ''' AND c.date <= ''' + CONVERT(VARCHAR, @DateTo, 101) + ''';';
EXEC sp_executesql @SQL;

⚠️ 注意：一定要用CONVERT确保日期格式正确，同时要防范SQL注入风险（如果变量是用户输入的话，这个方案不推荐）。

方案五：更新统计信息 #

有时候统计信息过时也会导致优化器预估错误，你可以更新CALENDAR表的统计信息：

UPDATE STATISTICS CALENDAR WITH FULLSCAN;

这个操作能让优化器拿到最新的数据分布情况，帮助它生成更准确的执行计划。

内容的提问来源于stack exchange，提问作者Saf-G