Question

我有以下查询

DECLARE @StartDate DATE = '2017-09-22'
DECLARE @EndDate DATE = '2017-09-23'

SELECT a.col1,
       a.col2,
       b.col1,
       b.col2,
       b.col3,
       a.col3
FROM   TableA a
       JOIN TableB b
           ON b.pred = a.pred
WHERE  b.col2 > @StartDate AND b.col2 < @EndDate

当我运行它并检查实际执行计划时，我可以看到最昂贵的运算符是聚簇索引扫描（索引在a.pred上）

但是，如果我按如下方式更改查询

SELECT a.col1,
       a.col2,
       b.col1,
       b.col2,
       b.col3,
       a.col3
FROM   TableA a
       JOIN TableB b
           ON b.pred = a.pred
WHERE  b.col2 > '2017-09-22' AND b.col2 < '2017-09-23'

删除索引扫描并使用索引搜索。

有人可以解释为什么会这样吗？在我看来，这与变量中的值可能是任何事情有关，因此SQL不知道如何计划执行。

有什么方法可以消除表扫描但仍然使用变量？（PS，这将被转换为一个以@StartDate和@EndDate为参数的存储过程）

修改

col2是DATETIME，但是，如果我使我的变量DATETIME问题仍然存在

Answer 1

SQL使计划可以重用变量。

当您使用变量时 - 它会在不知道您将传递的实际值的情况下编译查询。即使在这个sql batch值已知。但是它不需要为另一组传递参数重新编译查询。

因此，如果您对值进行硬编码 - 数据库会编译它，选择针对这些特定值优化的计划（例如，它会猜测通过日期检查的预期行数）。与使用变量时相比，它“至少不会更糟”。但是DB需要为另一组硬编码值重新编译它（因为查询的文本已经更改），这需要时间和内容compiled query cache存储取代其他有用的查询。

截至：

有什么方法可以消除表扫描但仍然使用变量？（PS，这将被转换为一个以@StartDate和@EndDate为参数的存储过程）

我认为b.col2上的非聚集索引可能是解决方案。该索引的关键字还可以包含b.pred作为代理键的一部分或包含（with include(pred)）。

Answer 2

这个查询有变量，这个问题中关于sql server的建议不知道变量的值，因此必须根据猜测的结果集大小来制定一个与你的问题相关的计划。

Why is SQL Server using index scan instead of index seek when WHERE clause contains parameterized values

但是，您提到要将此代码转换为存储过程。在将其转换为存储过程时，查询优化器应该能够嗅探变量的值并从中开发和执行计划。尝试将其转换为sproc并执行它。在这些条件下，查询计划应该会有所改进。

导致聚集索引扫描的日期参数

2 个答案: