Question

我有一个以datetime为参数的查询，我们观察到如果你通过变量提供datetime参数，那么查询需要比直接硬编码参数多2-3倍的时间，是否有任何理由或解决方案

以下查询大约需要5分钟才能返回结果

Declare @Date as DateTime   
Set @Date = '01/01/2009'

Select * from TempTable where effdate = @Date

虽然

  Select * from TempTable where effdate = '01/01/2009'

它在10-20秒后返回

并不总是我会在列上使用我想要搜索的索引。

根据kevchadders的建议，我看到了执行计划的巨大差异。带有日期变量的查询正在进行聚簇索引扫描，另一个正在执行索引查找。

Answer 1

通常的嫌疑是数据类型不匹配，这意味着该列是smalldatetime或varchar。 “datetime”具有更高的优先级，因此该列将被转换。

Answer 2

您是否看过两者的执行计划，看看是否能提出任何线索？

Answer 3

您应该查看查询的执行计划，看看是否存在任何差异。它们应该看起来完全相同，在这种情况下，查询的执行没有区别，任何性能差异都是由于数据库之前缓存了什么查询。

对于这样一个简单的查询，即使30-40秒也是如此。如果你在该字段上有索引，即使是非常大的表，也应该在几秒钟内得到结果。

对于实际查询，您当然应指定要返回的字段，而不是使用“select *”。通过仅返回实际需要的数据，可以减少从数据库服务器发送的数据量。例如，在此查询中，您知道结果字段的值对于结果中的所有行是什么，因此无需返回它。

Answer 4

我以前见过这个，并通过使用参数表而不是变量来解决它。

if object_id('myParameters') is not null drop table myParameters
Select cast('1996-05-01' as datetime) as myDate into myParameters

Select * from TempTable where effdate = (select max(myDate) from myParameters)

Answer 5

通过这样简单的查询，返回时间应该更多，更低。尝试使用EXPLAIN运行查询，即EXPLAIN Select * from TempTable where effdate = '01/01/2009'。如果没有使用索引的指示，则应在查询优化中添加一个（see the web for a tutorial）。

CREATE INDEX 'date_index' ON `TempTable` (`effdate`);

我不清楚为什么变量需要更长的时间，但是有一个索引应该加快查询速度以使差异可以忽略不计。

Answer 6

这可能是一个“参数嗅探”问题。尝试包括以下行：

OPTION (RECOMPILE)

在SQL查询结束时。

这里有一篇文章解释了什么参数嗅探：http://blogs.technet.com/b/mdegre/archive/2012/03/19/what-is-parameter-sniffing.aspx

SQL查询和datetime参数需要很长时间才能执行

6 个答案: