这是我遇到的问题。我正在查询的表有 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 很难比较时间？它不需要查看 的TIME部分datetime来查看它是否适合比较语句？我不知道。在这里，我抓住了稻草。
所以我的问题是，我怎样才能使这个速度相当快并且仍然保持我的@fifteenMinutesAgo活力？