2009-10-29 152 views
3

我有一個查詢,它將datetime作爲參數,我們觀察到的是,如果您通過變量提供datetime參數,Query執行的時間比如果你直接硬編碼參數,是否有任何原因或解決方案SQL查詢和日期時間參數需要很長時間來執行

下面的查詢需要大約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的建議,我看到了執行計劃的巨大差異。帶日期變量的查詢正在進行聚簇索引掃描,另一個正在做索引查找。

+3

是effdate一個varchar或日期時間字段? – 2009-10-29 09:24:41

+0

effdate是一個日期時間字段。 – rsapru 2009-10-30 12:13:28

回答

1

我以前見過這個,通過使用參數表而不是變量來解決它。

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) 
+0

這有幫助,但這是避免這個問題的唯一方法 – rsapru 2009-10-30 12:20:28

1

你看過兩個執行計劃,看看是否有任何線索?

0

有了這樣簡單的查詢,返回時間應該很多,很低。嘗試使用EXPLAIN運行查詢,即EXPLAIN Select * from TempTable where effdate = '01/01/2009'。如果沒有指示使用索引,則應該添加一個(查詢優化中的see the web for a tutorial)。

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

爲什麼變量需要更長的時間,但有一個指標應該足夠加快查詢,以賺取差價可以忽略它不完全清楚,我。

+0

沒有在SQL Server中解釋 – gbn 2009-10-29 09:56:30

1

您應該查看查詢的執行計劃以查看是否有任何區別。它們應該看起來完全一樣,在這種情況下,查詢的執行沒有任何區別,並且任何性能差異都是由於數據庫之前從此之後緩存了哪些查詢。

即使30-40秒對於這樣一個簡單的查詢來說也是很多的。如果您在該字段中有一個索引,則即使對於一個非常大的表格,您也應該在幾秒鐘內得到結果。

對於實際查詢,您當然應該指定要返回的字段而不是使用「select *」。通過僅返回實際需要的數據,可以減少從數據庫服務器發送的數據量。例如,在此查詢中,您知道結果中所有行的effdate字段的值是什麼,因此無需將其返回。

+0

+1「不要使用SELECT *如果你不需要所有的字段」 – Piskvor 2009-10-29 09:29:17

3

通常的嫌疑犯是數據類型不匹配,這意味着該列是smalldatetime或varchar。 「datetime」具有更高的優先級,所以該列將被轉換。

-1

這可能是一個'參數嗅探'問題。嘗試包括行:

OPTION (RECOMPILE) 

在您的SQL查詢結束。

有文章在這裏解釋什麼參數嗅探是:http://blogs.technet.com/b/mdegre/archive/2012/03/19/what-is-parameter-sniffing.aspx

+0

我可以看到OP中沒有存儲過程題。 – RandomSeed 2013-10-23 23:59:50

+0

OP只需要把它放在他/她的SELECT語句的末尾: – ninjaPixel 2013-10-24 07:54:42

+0

從TempTable中選擇* where effdate = @DATE OPTION(RECOMPILE) – ninjaPixel 2013-10-24 07:55:51