CPU瓶頸（一）

      CPU瓶頸問題可由硬體資源相對于目前負荷不足而導緻。 然而，過度的CPU使用率通常可以通過對查詢進行優化（特别是突然出現的增長但并沒有額外的負載或者其它的查詢發生在伺服器上）、定位所有可能的應用程式設計因素、優化系統配置去降低。在你匆匆去購買更快、更多的處理器之前，識别出最大的CPU帶寬消耗者，并且去檢視下是否可以優化這些查詢語句或者校正那些設計/配置因素。

      通常而言，為了确定伺服器是否處于CPU限制，性能螢幕是的最簡單工具之一。你應該去檢視Processor:%Processor Time計數器是否很高；如果每個處理器的平均處理時間持續高于80%，我們通常就可以認為已經遭遇了CPU瓶頸。

      在SQL Server内部，你也可以使用SQL Server自帶的動态管理視圖去檢查CPU瓶頸。SOS_SCHEDULER_YIELD類型的請求等待或者大量的“可被執行”的任務預示着“可被執行”的線程正在等待着被安排執行并且這個處理器上可能存在着CPU瓶頸。如果你已經啟用了資料收集器，Server Activity報表上的SQL Server Waits圖表将會幫助您很友善地随時追蹤CPU瓶頸。被消耗的CPU以及SOS_SCHEDULER_YIELD等待這兩項被收縮在了報表上的CPU 等待這個類别裡， 并且如果你看到了高CPU使用，你可以使用下鑽功能去檢視那條SQL語句消耗了最多的資源。

      下面的這個查詢語句幫助你從較高的層級檢視目前哪些緩存的批處理或者過程對CPU的占用最高。這個查詢語句對所有語句的CPU消耗時間進行彙總，并且按照plan_handle（意思是說它們屬于同一個批處理或者過程）進行分組。如果結果中有plan_handle對應的語句個數超過了一個的，你可能就不得不更深入地查找是哪個語句造成了最大的CPU占用。

   select top 50

         SUM(qs.total_worker_time) as total_cpu_time,

         SUM(qs.execution_count) as total_execution_count,

         COUNT(*) as number_of_statements,

         qs.plan_handle

   from sys.dm_exec_query_stats qs

   group by qs.plan_handle

   order by SUM(qs.total_worker_time) desc

    在本章接下來的内容裡，我們會讨論在SQL Server中通常會遇到的一些CPU密集使用的操作，也會提到對應的檢測及解決方法。