存储过程的 WHERE 子句中 DATEADD 的神秘行为

Question

这是我遇到的问题。我正在查询的表有 1.7 亿行。我编写了一个存储过程来对表中的最新条目进行简单查询。当我用这样的硬编码字符串编写WHERE 子句时：

SELECT top 500 a.field1 , a.field2, a.field3
FROM database..hugeTable a( nolock )
WHERE a.StartTime > '2012-07-17 10:10:35.477'

速度非常快。不到一秒。 StartTime 位于非聚集索引中。

然而，我真正想要的是：

DECLARE @fifteenMinutesAgo datetime;
SET @fifteenMinutesAgo = DATEADD(n , -15 , GETDATE());

SELECT top 500 a.field1 , a.field2, a.field3
FROM database..hugeTable a( nolock )
WHERE a.StartTime > @fifteenMinutesAgo

问题是当我运行第二个查询时，几乎需要 3 分钟！

于是我开始疯狂地四处寻找。我认为这可能是一个数据类型问题，所以我尝试了各种 CAST 和 CONVERT，但没有成功。我尝试使用OPTIMIZE FOR，但意识到它不适用于此版本的 SQL。我检查了StartTime的数据类型；它的类型是datetime。

我尝试的另一件事很奇怪，是这样的：

DECLARE @fifteenDaysAgo datetime;
SET @fifteenDaysAgo = DATEADD(d , -15 , GETDATE());

SELECT top 500 a.field1 , a.field2, a.field3
FROM database..hugeTable a( nolock )
WHERE a.StartTime > @fifteenDaysAgo

我将它从过去 15 分钟的搜索更改为过去 15 天。神奇的是，它又超快了！不到一秒。

这让我相信 SQL 很难比较时间？它不需要查看datetime 的TIME 部分来查看它是否适合比较语句？我不知道。在这里，我抓住了稻草。

所以我的问题是，我怎样才能使这个速度相当快并且仍然保持我的 @fifteenMinutesAgo 动态？

Answer 1

您的程序似乎有“parameter sniffing”问题。 WITH RECOMPILE 选项应该会有所帮助