我有一个简单的日期表(Date、DateID)，其中包含 1900 年 1 月 1 日到 2100 年 12 月 31 日之间的日期列表。
当使用 Between 运算符和硬编码参数值从表中进行选择时，我得到了一个正确的查询计划，其中包含 3 个估计行与 2 个实际行:
select v.Date from Dates v
where v.Date between '20130128' and '20130129';
但是，当用参数替换硬编码值时，查询计划会变为非常糟糕的计划，估计行数超过 6000 行，而实际行数只有 2 行:
select v.Date from Dates v
where v.Date between @startdate and @enddate;
查询计划本身是相同的，只是估计行数的差异导致参数化查询的运行速度比硬编码查询慢大约 4 倍。对于参数化版本运行速度如此慢的原因，我是否遗漏了什么，以及我可以为 SQL Server 提供哪些索引/提示来帮助它使用正确的查询计划？
一些附加信息:
- 使用简单的相等
=标准时不会出现此问题，它似乎是Between运算符特有的。 - 如果我将
option(recompile)添加到参数化查询的末尾，我会得到一个完美的查询计划，与硬编码查询相同。 - 日期表只有两列:Date 和 DateID，主键 DateID 列上有一个聚集索引，Date 列上有一个唯一的非聚集索引。所有数据均已更新。
- 查询计划对硬编码查询执行自动参数化，用 @1 和 @2 替换硬编码值，并将查询显示为大写。它似乎没有对参数化查询执行任何转换。
- 使用 SQL Server 2008 R2。
我知道足够的信息意识到怀疑这是某种参数嗅探问题。为什么不将 option(recompile) 添加到查询中？这被用作一个更大的复杂查询的一部分，我知道好的做法是让 SQL Server 做它的事情并尽可能重用缓存中的查询计划。
编辑和更新:感谢迄今为止的深思熟虑的回复。为了进一步细化问题，查询计划对上述两个查询都使用了一个完美的索引，但是为什么它没有认识到参数化查询的日期范围只有两天，为什么它认为范围是 6000行宽？尤其是当查看查询计划时，SQL Server 无论如何都会为硬编码查询执行自动参数化？在底层查询计划中，两个计划看起来相同，因为它们都是参数化的!
最佳答案
查询计划基于首次运行查询时的参数值。这称为parameter sniffing 。当您添加选项(重新编译)时，将为每次执行生成一个新计划。
查询计划根据 SQL 查询的哈希进行缓存。因此，两个版本的查询都有不同的缓存槽。
添加选项(重新编译)是一个很好的解决方案。您还可以使用:
option (optimize for (@startdate = '20130128', @enddate = '20130129'));
生成查询计划，就好像这些值已传入一样。
为了进行测试，您可以使用以下命令从缓存中删除所有计划:
DBCC FREEPROCCACHE
关于sql - "Between"运算符在使用参数时生成错误的查询计划，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14851328/