相信朋友對SQL Server性能調優相關的知識或多或少都有一些了解。雖然說現在NOSQL相關的技術非常的火熱，但是RMDB(關系型數據庫)與NOSQL是并存的，并且適用在各種的項目中。在一般的企業級開發中，主要還是RMDB占據主導地位。并且在互聯網項目中，也不是摒棄了RMDB，例如MySQL就在很多的互聯網應用中發揮著作用。所以，對數據庫的調優是個值得深入學習的課題。本系列文章，主要講述與SQL Server相關的調優知識，希望能夠為朋友們帶來一些幫助。 本篇提綱如下：

• 傳統SQL Server調優方式的比較
• 什么是DMV
• DMV簡單示例
• DMV可以解決哪些問題

傳統SQL Server調優方式的比較

我們平時可以采用很多工具對SQL Server的性能進行診斷分析與調優：性能計數器，SQL Server Profiler和Database Engine Tuning Advisor(數據庫引擎優化顧問，簡稱DTA)。下面我們就來對每一個簡單的說明一下，并且講述各自的優缺點。

性能計數器

對于使用Windows操作系統的開發朋友，對性能計數器已經不陌生了，最簡單的方式就是運行”perfmon”，就可以打開性能監視器的窗口，然后添加對應的計數器，進行監控。如下圖所示： 性能計數器每隔一段時間就回去收集相關的數據，并且我們還可以把這些數據保存起來，便于以后的分析。 優點：使用方便，并且數據收集的比較全面。因為這些操作系統是集成的，不需要額外的花費，就可以直接使用。 缺點：數據不夠準確，分析數據成本很高，并且對系統的性能產生影響。因為性能計數器在收集數據的時候，要定時的去抓取系統相關的數據，這樣，會對性能造成影響，如果抓取的時間間隔越短，那么對系統的影響就越大。另外，對于收集到的數據，也需要有經驗豐富的人去分析數據，并且如果要準確的分析出結果，需要收集大量的數據，人力和時間的成本也高。

SQL Server Profiler

每次談到SQL Server調優，勢必要講到SQL Server Profiler（為了后續的講述方便，我們將會把它簡稱為Profiler）。使用Profiler能夠捕獲一段時間內SQL執行的每個查詢的記錄。當數據庫服務器上有大量很少運行的查詢時，或者有特別的用戶查詢運行的時候，這個工具很有用。使用Profiler還能捕獲到指定時間段內的工作負荷，然后可以在恢復的數據庫系統中進行重現。 下面就是一個使用Profiler的界面： 在使用Profiler的時候，在哪里啟動Profiler以及將跟蹤的數據保存在何處，是一個特別需要考慮的問題。下面，我們就用來對比地看看各種不同的情況。

啟動Profiler的位置	跟蹤文件	說明
在正在監視的數據庫服務器上啟動Profiler的跟蹤	將跟蹤的數據文件保存到服務器的文件系統或共享目錄中	優點：這種方式適用于非生產環境和低負載服務器上的開發和對數據庫應用進行性能診斷和跟蹤。 缺點：加大了服務器的I/O讀寫操作
在本機開啟Profiler，連接遠程的數據庫服務器	將跟蹤的數據文件保存在本地	優點：減小了數據庫服務器的I/O操作。 缺點：加大了網絡傳輸的壓力，占用數據庫服務器的網絡資源和CPU資源。因為需要將大量的跟蹤數據傳送到本機，這樣占用了網絡資源；而數據在傳輸的時候，需要CPU將之序列化，加大了CPU的操作。

數據庫引擎優化顧問（DTA） DTA一般需要和Sql Server Profiler結合在一起使用。DTA主要是對Profiler中收集到的數據進行純數據的綜合分析，所以它分析結果的準確性非常依賴于Profiler收集的數據量的多少。Profiler收集的數據越多，那么DTA分析的就越準確，但是這樣也對數據庫服務器的壓力越大，反之。所以，一般不建議在大負載或者生產環境下的數據庫服務器上面采用。 如果有需要在大負載，或者生產環境下對數據庫的性能進行分析與調優，那如何處理？ 這就是我們本次系列文章要討論的話題。

什么是DMV

使用過SQL Server的朋友，對DMV（Dynamic Management Views，動態管理視圖）或多或少都有一些了解或者耳聞。其實DMV就是SQL Server內核的元數據，通過對內部的元數據的分析，我們快速而準確獲取很多與SQL Server內部相關的信息，從而進行性能分析。 當查詢在SQL Server中運行時，SQL Server會自動的將此次活動的相關信息記錄下來，并且保存在內存之中，這些活動信息，就稱之為：DMV。 不同類型的DMV信息，有不同的用途，例如，可以相關的DMV來對性能進行診斷，從而提升性能，或對數據庫的運行進行監控，或解決故障等。 DMV是以SQL Server實例為級別進行保存的。也就說，如果在服務器上面，安裝了一個SQL Server，那么此時這個SQL Server就是一個實例，那么這個實例里面的所有的數據庫的DMV都是保存在相同的內存中。當然，我們在使用的時候，可以根據需要只提取更低級別的DMV，例如提取某個數據庫的DMV，某個表的DMV，甚至是某個查詢的DMV。 因為DMV信息是保存在內存中的，我們不需要額外的操作，只需要將這些信息取出來，按照我們的要求進行運算，統計，分析就夠了，獲取信息的數據非常快，并且不會對服務器產生壓力。另外，因為DMV是SQL Server本身保存的，并且已經做了統計的信息，所以，數據更加的接近于數據庫本身的狀態。 SQL Server運行的時候越長，DMV中保存的信息就越多（當然，DMV非常小，不會對內存造成壓力），利用DMV分析就越準確。這一點和之前的Profiler和DTA是完全不一樣的。唯一的一個問題就是：每次SQL Server服務重啟，這些保存在內存中的DMV信息就沒有了，又是從頭開始，慢慢的保存。當然，對于這個問題，我們有很多的解決方案，例如，我們可以定期的將DMV的信息導出，保存在磁盤上。 DMV包含了的信息有很多：索引相關的，查詢執行相關的，還有SQL Server OS相關的，Common Language Runtime（CLR）相關的，事務相關，安全相關的，資源管理相關的，數據備份相關的，I/O相關，全文查找相關，數據庫鏡像相關的，等等信息。所以，我們完全可以使用已經保存在DMV中的信息來進行我們的分析。 因為SQL Server內部的DMV很多，我們本次系類的文章注重在性能分析與調優上，所以，我們主要關注以下幾類DMV：索引相關，執行相關，SQL Server OS相關，CLR相關，事務相關，I/O相關，數據庫相關。 下面，我們分析一個查詢的運行，看看在這個過程中SQL Server都記錄了哪些信息（或者說，DMV中保存了什么信息）：

查詢的執行計劃（即描述了一個查詢是如何被執行的）

什么索引被使用

什么索引本來應該被用到，但是又沒有使用。（因為此時存在缺失索引的性能問題）

I/O的狀態（包含邏輯I/O操作和物理的I/O操作）

查詢執行消耗的時間

查詢等待其他資源消耗的時間

查詢在等待什么資源

通過分析這些信息，不僅僅可以使得我們更好的理解查詢的是如何工作的，并且還可以讓我們思考如何更加合理，高效的使用資源，提高性能。 一般而言，在使用DMV的時候，我們很多時候也需要將其與DMF（Dynamic Management Functions）一起使用。我們可以簡單的將DMF理解為SQL Server內部的一系列函數。例如，通過分析sys.dm_exec_query_stats，可以知道查詢的相關信息，如果將sys.dm_exec_query_stats里面的sql_handle傳給sys.dm_exec_sql_text，那么，我們就可以知道查詢的語句的內容。

DMV簡單示例

為了使得大家對DMV有更加深入的了解，我們首先來看看一個使用DMV來找出那些查詢運行的最慢。（朋友們可能對這里提到的相關的DMV和DMF不太熟悉，沒關系，后續文章會介紹） 在SQL Server的查詢分析器中，運行一下SQL 語句： 此時，運行的結果如下： 在這個查詢中，我們主要是通過將sys.dm_exec_query_stats這個DMV與sys.dm_exec_sql_text和sys.dm_exec_query_plan這兩個DMF結合，通過分析查詢所消耗的時間，然后按照從高到低進行排序，選出前20個進行展示。 從這個示例中，我們可以知道幾點：

查詢DMV時，應該盡可能的將對數據庫的影響降到最小。所以，我們在查詢的最上面，加上了：SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。因為每次在運行查詢的時候，或多或少的會對數據庫產生不同程度的鎖定，并且鎖定的級別各不一樣。通過上面的設置，就告訴SQL Server，接下來的執行的查詢將鎖定的級別定為：Read Uncommitted。從而將影響減小到最小。

每次進行性能問題診斷的時候，首先要解決最嚴重的性能問題。所以，我們此處只是找出前20個運行最慢的查詢語句。

雖然原生的DMV信息提供了很多的信息，但是很多時候需要對DMV進行復雜的統計分析。（這個成本比分析SQL Server Profiler收集到的數據小，也更加簡單，準確。）

DMV可以解決哪些問題

看完了上面的簡單的例子之后，相信朋友們對DMV有了一個感性的認識，下面，我們就來看看，利用DMV，我們可以解決哪些問題。

故障診斷

診斷就是要識別出問題的所在。有很多的方式和工具可以幫助我們達到這個目的，但是，有了DMV，可能效率會更快：沒有什么比分析SQL Server內部的元數據來的更快。 很多時候，對問題的診斷也是性能調優的第一步，搞清楚了問題，才好對癥下藥。 利用DMV可以診斷出以下問題：最慢的查詢語句，常見的等待與阻塞，沒有用的索引，大量的I/O操作，利用率最低的執行計劃。 正如之前所說，我們可以在不同的級別上面分析問題，例如從整個服務器級別，數據庫級別，甚至是某個查詢。我們可以通過在獲取DMV信息時，設置獲取信息的條件來辦到。例如，在上一小節的示例中，就是獲取整個SQL Server中找出最慢的前20個查詢，如果需要，我們完全可以將條件縮小到某個數據庫。 很多時候，在識別問題的時候，不是那么容易，僅僅通過一個DMV就搞定了的，需要和DMF結合。甚至要和其他的DMV一起結合分析（在后續文章中，我們會理解的更加深刻）。 診斷出了問題，是一個方面，解決問題也尤為重要。

性能調優

性能調優主要是利用相關的技巧技術之前診斷中出現的問題，從而提升性能。我們后續會詳細講述，這里就不再贅述了。

狀態監控

很多的DMV（特別是那些以 sys.dm_exec_開頭的）都反映了數據庫服務器執行的狀態。通過查看這些DMV，我們可以清楚的知道數據庫服務器的現在的狀態和歷史的狀態（當然，如何SQL Server服務被重啟，那么之前的信息都丟失了，除非定期做了保存）。例如，數據庫需要做批處理等長時間的操作，如果其中操作執行超時或運行的非常慢，這個時候，我們就可以查詢DMV來分析。如果采用Profiler或者相關的Profiler腳本跟蹤，會對數據庫服務器的壓力相當大。再如，還可以分析數據庫中現在有哪些查詢在運行，有多少請求在處理，打開多少連接等等，主要是對數據庫的操作，都可以通過DMV查詢到。 到這里，不知道朋友們是否有點“躍躍欲試”的沖動，我們在后續，會為朋友們一一奉上。敬請關注。 ???

轉載于:https://blog.51cto.com/yanyangtian/755152

總結

以上是生活随笔為你收集整理的SQL Server大负载的生产环境下的性能优化：初识元数据优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。