使用OleDB從.NET查詢SQL Server 2005時的大小寫敏感性

我有一個查詢正在從.NET應用程序執行到SQL Server數據庫，並且似乎需要很長時間才能完成（5分鐘以上）。我在c＃中創建了一個測試應用程序，試圖查看這麼長時間的討論（查詢應該很快返回）。使用OleDB從.NET查詢SQL Server 2005時的大小寫敏感性

正如我通過加入中的元件以看到哪個部分正在採取只要重建該查詢，我結束了幾乎逐字重構所述查詢，其中，唯一的區別是在原始查詢和一個大寫差的空間。這種差異在約100毫秒內返回了結果。

以前有人看過這個嗎？我想知道服務器中是否有服務關閉（因爲同事有同樣的問題）或我們的電腦上。

在此先感謝您的幫助。

代碼示例以下（末尾在查詢的第一線的差值（fk_source與FK _Source）：

//Original 
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " + 
     "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " + 
     "CONVERT(datetime,'01-01-2009',105) and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn); 

//Rebuilt 
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " + 
     "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " + 
     "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);

來源

2008-09-29 Fry

我懷疑這是一個過程緩存問題。存儲過程的一個好處是該計劃是爲您儲存的，這可以加快速度。不幸的是，有可能在緩存中得到一個糟糕的計劃（即使使用動態查詢）。

只是爲了好玩，我檢查了我的程序緩存，運行了特別查詢，再次檢查，然後用不同的capitlization運行相同的查詢，我驚訝地發現程序數量更高。

試試這個....

連接到SQL Server Management Studio。

DBCC MemoryStatus 

Select Columns... From TABLES.... Where.... 

dbcc MemoryStatus 

Select Columns... From tables.... Where.... 

dbcc MemoryStatus

我想你會發現當語句改變時（即使唯一的改變是區分大小寫的），TotalProcs會改變。

更新您的統計信息可能會有幫助。這是一個相當慢的過程，所以你可能想在緩慢的時期運行。

來源

2008-09-29 20:04:19

由於您使用SQL Server 2005中，你有沒有試着用一個SqlCommand而不是OleDbCommand對象？

來源

2008-09-29 18:36:09

如果你使用SQL Server _AND_淨，這很有道理。 – 2008-09-29 18:37:59

是的，但它的意思是可以與其他數據庫互換，我們只是在SQL服務器中注意到這種行爲，所以我特別詢問了它。 – Fry 2008-10-06 22:25:12

我在查詢中沒有看到會影響性能的區別 - 緩存或索引/統計信息在運行之間發生了哪些變化？執行計劃可能因統計信息或索引更改而發生更改。

關於案例：如果數據庫設置爲區分大小寫，但案例可能很重要，但是對於在區分大小寫的數據庫中運行的兩個查詢，必須以兩種格式命名列 - 查詢解析器將服從案例 - 它不會導致性能差異。

來源

2008-09-29 18:38:32

首先，你是否100％肯定它的查詢出錯了？檢查sql server中的跟蹤配置文件以查看它在數據庫中佔用多長時間。其次，你是否得到相同數量的結果。在sql server中默認大小寫不重要，但它可能已經被設置爲不同。

來源

2008-09-29 18:39:26 gbjbaanb

如果我有一個需要「5+分鐘」的查詢，我不會擔心匹配字符串的情況需要100毫秒。

來源

2008-09-29 18:40:51

2個查詢中的差異，1個在5分鐘以內返回，1個在100毫秒內返回 – Fry 2008-10-06 22:26:18

感謝所有的答案，我會到每個響應依次爲：

1）拉斯，我同意在該SQLConnection會更好，但不幸的是我沒有得到設置連接類型。我剛創建了一個小應用程序來測試此查詢，但查詢是在更大的應用程序中動態創建的。 2）gbjbaanb，這不是服務器問題，我認爲，因爲我可以在同一時間從管理工作室運行兩個查詢，它似乎只是在.net（1.1和2.0）中運行oledb時出現問題）。我們已經在其上運行了一個分析器，並且跟蹤文件證實，當以這種方式調用時，需要5分鐘才能完成查詢。

3）Joel Coehoorn，同意，但我真正想在這裏得到的是「爲什麼」，因爲現在我們不知道這個問題有多大以及它在哪裏。

4）Cade Roux，它的差別非常重現，所以我不認爲這是索引更改或緩存問題，因爲我已經將測試連續運行並獲得了相同的結果，並且它們需要大約相同的時間在SQL Server中運行。

來源

2008-09-29 19:04:10 Fry

感謝G馬斯特羅斯提供了最完整的答案，儘管回顧卡德提出的統計數據更新。但是，G Mastos的解決方案更適合我的SQL Server體驗級別。

感謝您幫助大家！

我要去看看爲什麼這種看似無辜的差異有這麼大的後果

來源

2008-09-29 22:12:55 Fry

使用OleDB從.NET查詢SQL Server 2005時的大小寫敏感性

回答

相關問題