查询工作几个月现在超时

我有一个查询运行从一个Delphi应用程序，突然开始超时后运行完好几个月后超时。进一步，当运行时，它会降低服务器的爬行留下的其他用户认为系统已经崩溃从Management Studio中运行我停止查询5分多钟纺服务器ID SQLEXPRESS 2008 R2查询工作几个月现在超时

的现在得罪查询后

SELECT  * 
FROM  SignelOutilsListeJobs_View4 
WHERE  (CreatedDate > (GETDATE() - 365))

为了让这里有趣的是所需时间&行返回时，我只是改变的天数回。活动监视器似乎没有显示超过查询运行

SELECT  * 
FROM  SignelOutilsListeJobs_View4 -- 00.00.02 38882 ROWS 

SELECT  * 
FROM  SignelOutilsListeJobs_View4 
WHERE  (CreatedDate > (GETDATE() - 600)) -- 00.00.02 16217 ROWS 


SELECT  * 
FROM  SignelOutilsListeJobs_View4 
WHERE  (CreatedDate > (GETDATE() - 500)) -- 00.00.02 13013 ROWS 


SELECT  * 
FROM  SignelOutilsListeJobs_View4 
WHERE  (CreatedDate > (GETDATE() - 200)) -- 00.00.12 4118 ROWS

因此，我想知道这里发生了什么？有任何想法吗？

感谢

来源

2015-10-22 Marc

第一个猜测：一个坏的查询计划已经得到缓存该查询。 –

...为什么不直接在Delphi代码中预先计算日期限制，然后将其作为查询参数传递？它可能不太容易出错，允许轻松地重复使用具有各种偏移量的相同单个语句，并且还与所有数据库后端兼容... –

不是性能挑战的答案，但应该使用DATEADD而不是数学快捷方式。很明显你在做什么，不依赖于可能改变的违约行为。 DATEADD（day，-200，getdate（）） –

从GETDATE (Transact-SQL)：

使用SWITCHOFFSET与函数GETDATE（）可能会导致因为查询优化器是无法获得的GETDATE值准确基数估计查询运行缓慢。我们建议您预先计算GETDATE值，然后在查询中指定该值，如以下示例所示。另外，使用OPTION（RECOMPILE）查询提示强制查询优化器在下次执行相同查询时重新编译查询计划。然后，优化器将对GETDATE（）进行准确的基数估计，并生成更高效的查询计划。

换句话说，你可以尝试编辑查询，如下所示：

SELECT * 
FROM SignelOutilsListeJobs_View4 
WHERE CreatedDate > (GETDATE() - 200) OPTION (RECOMPILE)

作为替代上面，你可以考虑在视图中创建一个唯一聚集索引 ：

CREATE UNIQUE CLUSTERED INDEX SignelOutilsListeJobs_unique_index1 
ON SignelOutilsListeJobs_View4 (CreatedDate, <some unique key>)

从微软的TechNet：

来源

2015-10-22 14:12:25 fantaghirocco

我尝试了以下三个版本导致了同样的结果的查询，请注意，我停止了查询等待一分钟后，用户对我的门敲前 - SELECT * FROM SignelOutilsListeJobs_View4 WHERE（CreatedDate>（GETDATE（） - 365））OPTION（RECOMPILE） - SELECT * FROM SignelOutilsListeJobs_View4 WHERE（CreatedDate> DATEADD（日，-365，GETDATE（）））OPTION（RECOMPILE） - 声明ADATE日期-AT CHAR除去POST SET ADATE = GETDATE（） - 365 SELECT * FROM SignelOutilsLi steJobs_View4 WHERE（CreatedDate> @ADATE）选项（RECOMPILE） – Marc

查询工作几个月现在超时

回答

相关问题