使用訂單時，SQL Server連接查詢速度慢

U_Accounts（含小錶行）
SMS_Buffer（大表含短信隊列）

下面是一個簡單的查詢，當我們使用ORDER BY

Select SMS_Buffer.msg_id, 
     SMS_Buffer.u_id, 
     SMS_Buffer.msgtxt, 
     SMS_Buffer.m_priority, 
     U_Accounts.U_Priority 
From SMS_Buffer 
JOIN U_Accounts ON Sms_Buffer.u_id = U_Accounts.u_id 
where U_Accounts.u_msgpush=1 
Order by U_Accounts.u_priority DESC, 
     SMS_Buffer.m_priority DESC, 
     SMS_Buffer.m_id DESC

上面的查詢變得緩慢子句SMS_Buffer.m_priority DESC, SMS_Buffer.m_id DESC對於記錄小於100000行的SMS_Buffer表，但w當它增長查詢變得非常緩慢。

請您向我們提供的解決方案爲上述查詢的性能更好。

我們試圖創建聚簇，非聚集索引，但並未有任何的成功。

來源

2012-02-14 user1209658

請格式化你的代碼接下來的時間，這是非常難以閱讀文本 – Blorgbeard 2012-02-14 17:57:19

你創造什麼指標，什麼是你的執行計劃的牆？ – HLGEM 2012-02-14 18:11:10

並定義緩慢，你有什麼鍵... – 2012-02-14 18:16:46

這不能沒有進一步的信息，以索引和理想的執行計劃適當回答的問題，但你看到的行爲，從而以較少行的快速查詢看到業績迅速惡化，當它達到一定的量通常表示使用全表掃描的查詢，當表適合內存時這並不算太壞，但當數據增長得如此之大以至於數據被寫入磁盤時，它會發生災難性的惡化（磁盤I/O比操作慢幾個數量級在記憶中，所以你點擊這個點通常是顯而易見的）。

你唯一的解決這種方式是爲了檢查執行計劃，並確定是什麼原因造成的全面掃描，但沒有那個必要的信息，你正在試圖解決這個盲人。

來源

2012-02-14 21:24:32 Cruachan

你最好的辦法是引用執行計劃 - 這將是最好的 - [鏈接]（http://www.simple-talk.com/sql/performance/execution-plan-基本/） – Aklopper 2012-02-17 12:24:41

當我遇到同樣的排序從this question事情弗萊的答案的幫助。簡而言之，更新統計可能是解決方案。在SQL EXEC sp_updatestats。

我正在處理2個子查詢和一個表，然後排序。這3個結果集都在5,000行以下，添加Order By將從12秒到5分鐘。這是非常緩慢的。更新統計數據後，它在1秒內運行。

來源

2014-05-02 18:26:18 isopropanol

使用訂單時，SQL Server連接查詢速度慢

回答

相關問題