Sql效能最佳化總結（續）- sql語句最佳化篇

Sql效能最佳化總結（續）- sql語句最佳化篇

 

今晚繼續進行Sql效能問題的分享，今天主要是一些具體的sql最佳化方法和思路分享，若看過後你也有其他想法，歡迎一起探討，好了，進入今天的主題。

 

針對性地對一些耗資源嚴重的具體應用進行最佳化

 

出現效能問題時，首先要做的是什嗎？這個問題我問過不少同事，有人說憑經驗對出問題的sql進行最佳化，如我們一般說的要合理使用索引，盡量不要使用前面帶*號的Like語句，不要再比較操作符前邊進行計算或使用函數等等，這些道路都是對的，但經驗有時候不一定能解決問題。問題出現時，首先要做的是確定問題點是什麼，只有正確的找到問題後才能有針對性的解決問題。下面簡單介紹我們一般從哪些角度入手，來確定問題所在。

 

1.首先從業務上理解該處功能，理解使用者的真正意圖，使用者真正關注的是什麼，想要的是什麼資料，是否有變通簡潔的方法達到使用者要求。而非使用複雜sql查詢。其實有些時候進行變通的修改，同樣能達到目的，但是採用的sql語句已經極大地簡化了。這是解決效能問題的優先要考慮的。

 

2.對固定的sql進行最佳化時，一定要關注查詢相關的資料量，關注資料量的大小，有些時候使用者進行一個查詢，若沒有處理好查詢條件的話，返回的記錄集合太大，這對使用者來說，其實意義不大，關鍵是這樣必然會導致較多的磁碟IO，效能問題是必然的。除非是使用者真的需要這麼多資料，但事實證明，多數都不是的，所以著眼點是怎樣限制返回的記錄集的大小或查詢中使用的臨時中間資料集合的大小。這樣才能使你的最佳化達到效果，起到作用。

下面簡單介紹幾種常用的檢查問題sql的方法。

 

當然其中是有些技巧的，如：

1. 使用 set statistics io on 檢查實際的磁碟IO資訊，物理讀、邏輯讀等資訊，這個是一個簡單有效參考資料，在筆者以往的經驗中，也是主要的參考資料。

 

在查詢分析器中貼出問題sql，使用set statistics io  為on，也可以在空白處點擊右鍵，選擇<查詢選項>，

選擇<進階>

勾選Set Statistics Io 。

 

執行查詢，除了得到結果集合以外，還可以得到本次查詢相關的IO資訊，如：

我們一般關注邏輯讀的次數，當多個表聯集查詢時，這裡會現時每一個表的IO資訊，當某個表的邏輯讀的次數很大時，你就要重點關注和分析這個表了，是不是查詢時涉及到這個表中的記錄條數過多，是不是沒有合理使用到Index,是不是可以增加其它的過濾條件來減少相關的記錄集合等等。下面是簡單說明：

 

輸出項 含義

Table       表的名稱。

Scan count     執行的索引或表掃描數。

logical reads 從資料緩衝讀取的頁數。

physical reads        從磁碟讀取的頁數。

read-ahead reads           為進行查詢而放入緩衝的頁數。

lob logical reads    從資料緩衝讀取的 text、ntext、image 或大實值型別 (varchar(max)、nvarchar(max)、varbinary(max)) 頁的數目。

lob physical reads          從磁碟讀取的 text、ntext、image 或大實值型別頁的數目。

lob read-ahead reads   為進行查詢而放入緩衝的 text、ntext、image 或大實值型別頁的數目。

 

磁碟IO相關資訊先介紹到這裡，另外一個參考資料是使用 set statistics time on 參考顯示分析、編譯和執行語句所需的毫秒數。具體的使用方法同set statistics io on 基本相同，只不過顯示的是本次查詢所使用的分析編譯、執行等的時間資訊。聰明的你一定一看就明白了。在此不再贅述。

 

1. 使用 set statistics profile on 參考顯示當前語句執行的設定檔資訊，執行步驟等資訊，使用方法同上。

 

 

執行查詢後，除了顯示所執行的結果集合外，還另外顯示本次sql語句執行的相關配置資訊，採用記錄樹的形式顯示，對應執行計畫中的各個步驟，比如某個步驟使用的索引類型，評估行數，IO資訊，時間資訊等。這些資訊都可以用來參考，以確定該段sql語句的問題在哪裡。

 

參考當前語句的估計的執行計畫或實際的執行計畫，分析當前語句執行時SQL Server 查詢最佳化工具所選擇的資料檢索方法。