在一臺服務器上查詢兩個數據庫的性能

我看過這個：The Same SQL Query takes longer to run in one DB than another DB under the same server但我仍然爲此感到困惑。我已經在兩個數據庫上進行了測試，具有完全相同的查詢計劃，但在測試數據庫中，此查詢在20ms內運行，在開發數據庫上，這需要1分鐘以上。在一臺服務器上查詢兩個數據庫的性能

需要注意的是，測試數據庫是當前時間點的開發數據庫的一個相同的副本（請注意，自問這個問題以來發生了輕微的模式更改 - 請參閱編輯以獲取更多信息）。我運行的查詢是這樣的：

SELECT 
    pn.PARTNO, 
    LogisticsComment, 
    Length, 
    Width, 
    Height, 
    Weight 
FROM [partDB] pn 
INNER JOIN [storeLines] sl 
ON pn.PARTNO = sl.PARTNO 
INNER JOIN [storeRequests] sr 
ON sl.ITEMID = sr.LINEITEMS 
WHERE sr.SERIAL = 'S14566'

這是查詢執行計劃：

我在茫然，這可能是導致此。另外需要注意的是，這個鏈接的問題有200萬條記錄 - 這個查詢目前應該返回26條記錄。

編輯：對於延遲的歉意，生活中有投擲曲線球的習慣。

根據要求，請爲現場和測試系統找到XML。

發展： PasteBin link

測試：兩個 PasteBin link

和實際執行計劃生活和測試系統：

發展：

測試：

編輯2：我做了一個架構比較，發現兩個能在此查詢， 'TMTPARTNO' 和 'LogisticsComment' 列有不同的數據類型 - 在測試系統中，它們分別是varchar（50）和nvarchar（1500），而在實時系統中，它們是char（18）和nchar（1500）。在不改變實時系統中的數據類型的情況下，我想知道性能的影響可能在於'LogisticsComment'字段中使用了多少字節？

來源

2015-12-03 DeeKayy90

在問題中包含**實際**執行計劃的XML，用於**快速和慢速查詢。在SSMS中，在菜單查詢 - 包括實際執行計劃中打勾。在包含查詢結果和計劃的窗口中右鍵單擊並顯示執行計劃XML。 –

Hi @VladimirBaranov，對延遲道歉。按照要求，我已經包含了AEP和這兩個查詢的XML。由於SO有3萬個字符限制，我必須從XML中刪除一些信息，但請不要猶豫，如果您認爲問題出在這些區域內，請告訴我，我會盡快讓他們發佈可能。 – DeeKayy90

對於投票選擇'關閉'的人，你能否讓我知道爲什麼/這種交換更適合？我在這裏發帖認爲這個問題與查詢有關，但它可能是一個結構問題 - 它會更適合dba嗎？或者也許另外一個？ – DeeKayy90

在問題的開始，您正在談論測試vs開發數據庫;稍後您會參考測試與實況。這很混亂。

當兩個執行計劃尋找有一個警告：

Live - Cardinality Estimate Expression="CONVERT_IMPLICIT(nchar(18),[pn].[PartNumber],0)" 

Test - Cardinality Estimate Expression="CONVERT_IMPLICIT(nvarchar(50),[pn].[PartNumber],0)"

什麼領域在這兩個數據庫pn.PartNumber和sl.PartNumber的類型？

顯然它們在兩種情況下都不匹配，這並不好。可能有一種情況是不匹配導致更嚴重的後果。行的估計數目略有不同（3對4），並返回的行實際數目是26.

在計劃的另一個區別：

直播計劃上STORES-REQ-LINK被調用STORES-REQ-LINK_SerialIndex使用索引。

測試計劃使用名爲STORES-REQ-LINK_Index02122015的STORES-REQ-LINK上的索引。

這些指標是否相同？

表格基數略有不同：110077 vs 106488,97535 vs 92892，這解釋了估計行數的細微差異。

因此，數據庫在結構和實際數據上都不相同。使它們相同並再次比較性能是有意義的。說完所有這些，你的表格並不大（〜100K行），所以這種查詢不應該花費幾分鐘的時間。

這兩個數據庫位於同一臺服務器上，所以CPU和內存應該相同。它們位於相同的硬盤上嗎？

但是，這些計劃非常相似，查詢處理的實際數據大小很小（77KB vs 39KB），所以這種性能上的巨大差異很可能是由某些阻塞/鎖定引起的。緩慢的查詢可能只是在等待一些資源。這兩個數據庫有什麼樣的活動？

來源

2015-12-14 11:33:35

關於命名不一致的道歉 - 我已經在原文中解決了這個問題。至於sl.PartNumber和pn.PartNumber的字段類型，確實它們在開發系統中不匹配;然而它們在測試系統中很接近但並不完全相同。索引是相同的，但是在生成/開發計劃中的名稱是在創建時命名的，但是在測試中它只剩下一個datestamp索引（再次用於測試）。是的，它們在同一個磁盤上 - 但是，開發系統比測試系統接收更多的流量。大約是測試的20倍。 – DeeKayy90

謝謝你的回答弗拉基米爾，併爲你的時間。我將更深入地學習XML以理解它，但出於好奇之外，當比較兩個執行計劃時，您尤其期待什麼？我希望能夠這樣學習，以便下次我不會在沒有一些基礎知識的情況下提出問題。謝謝！ – DeeKayy90

@ DeeKayy90，在這種情況下，計劃確實看起來非常相似，這表明緩慢的系統必須等待一些東西。或者還有其他一些外部原因。如果性能差異是由計劃或數據的實質性差異造成的，您會看到實際處理數據的大小不同; IO（讀取次數）;計劃形狀。你只看平面形狀，下一步是檢查IO（讀取），行數，處理的字節數。看過所有這些，你可以確認問題在別的地方。然後查看等待統計數據，服務器的整體perf數據。 –

在一臺服務器上查詢兩個數據庫的性能

回答

相關問題