CPU使用率較高時，容易影響查詢性能。本文介紹如何查看CPU使用情況以及排查CPU問題。
查看CPU使用情況
RDS管理控制臺提供多種查看CPU使用情況的方法：
監控與報警
在控制臺的監控與報警頁面，單擊舊版監控頁簽，在資源監控內，可以查看CPU使用率信息。
自治服務
實例不能是RDS SQL Server 2008 R2云盤版。
在控制臺的自治服務 > 性能優化頁面，單擊性能洞察頁簽，可以查看CPU使用率信息。
共享型實例會復用CPU，因此即使實例本身的CPU使用率不高，也可能會因為復用CPU導致性能出現瓶頸，如果對數據庫性能的穩定性要求較高，建議使用獨享型規格的實例。
分析性能指標
原因
對于突發的CPU使用率明顯增高情況，常見原因有如下幾種：
數據庫查詢請求數量突然增加。例如業務負載突然增加，或是數據緩存服務層出現緩存穿透等。
查詢請求的開銷突然增加。例如應用中出現新的低效查詢請求，或是某些查詢語句的執行計劃發生了改變等。
查詢語句的執行計劃編譯頻率明顯增加。例如當實例的緩存壓力增大時，會導致執行計劃緩存數量明顯下降和緩存命中率下降，并進一步造成查詢語句編譯的頻率和整體開銷明顯增加。
分析
在監控中重點關注如下性能指標，可以初步判斷是哪種原因導致的CPU使用率增高。
QPS
如果QPS增高和CPU使用率增高保持一致，說明是數據庫查詢請求數量增加導致的CPU使用率增高，即CPU高的原因不在數據庫層面，應當從應用層面分析是什么原因導致數據庫查詢請求數量增加。
Page_Lookups/sec
Page_Lookups/sec是指執行中的查詢請求平均每秒累積的邏輯讀頁數，Page_Lookups/sec高的原因通常是查詢語句的執行效率較差，該值如果較高，則查詢請求的CPU開銷也一定較高。如果Page_Lookups/sec的增高和CPU使用率的增高保持一致，而QPS變化不大，說明數據庫中出現了查詢語句執行開銷增高的情況，需要進一步分析是哪些類型的查詢語句導致了較高的CPU資源消耗，并針對具體的查詢語句進行優化。
Sqlcompliations
Sqlcompliations是指平均每秒查詢請求的編譯次數，如果Sqlcompliations的增高和CPU使用率的增高保持一致，而QPS變化不大，可能是查詢請求的編譯開銷導致的CPU增高，還可以進一步檢查與執行計劃緩存數量相關的性能指標Cache_Object_Counts和Cache_Pages，如果這些性能指標的值下降也很明顯，則較大可能是實例的緩存壓力過大。提高實例的內存規格是比較有效的解決方法。
參考案例
以下為一個實際的參考案例。
從CPU使用率的監控中可以看到，CPU的升高主要出現在9:10~9:20和9:30~9:40這兩個時段。該實時段內實例的QPS并沒有增加，9:40之后QPS才開始增加，因此CPU使用率的增高并不是數據庫查詢請求數量的增加導致的。
同時段Sqlcompliations的值也無明顯升高，并且其絕對值也很低，因此查詢編譯開銷也不是導致CPU升高的原因。
Page_Lookups/sec的值增高與CPU使用率的增高時間基本一致，因此較大的可能性是9:10~9:20和9:30~9:40這兩個時段內有某些執行開銷較高的查詢請求存在，導致了實例整體CPU使用率的明顯升高。
在這種情況下，需要進一步分析在上述時段內有哪些查詢語句的執行導致了較高的CPU資源消耗。另外Page_Lookups/sec的值升高一定會導致CPU使用率升高，但也會有些查詢語句的執行開銷很高而邏輯讀開銷并不高，這時要分析對應時段內的查詢語句以定位原因，您可以通過SQL審計查看相關語句。
分析活動會話
原因
導致RDS SQL Server實例的CPU使用率突然增高的各種原因中，最常見的是數據庫中出現了某些執行效率較差的查詢語句。您可以使用自治服務中性能洞察功能的平均活躍會話AAS（Average Active Sessions）定位和分析這類查詢語句。
分析
RDS會每10秒檢查一次SQL Server實例中的活動會話（Active Session）信息，并記錄當前處于活動狀態的查詢請求的SQL語句、Query Hash、執行計劃及等待事件類型等。CPU開銷高的查詢語句處于執行狀態的過程中有很大可能其等待類型（Waits）是CPU。
SQL Hash列的值是對SQL語句進行結構參數化之后的哈希值，用于標識在語句結構上完全相同的一類SQL語句，便于將SQL語句按照結構進行歸類聚合統計，利用SQL Hash可以直接在系統視圖sys.dm_exec_query_stats中基于query_hash列的值進行檢索，從而獲得該語句的最新執行情況統計信息。
建議的排查方法如下：
單擊SQL Hash列的超鏈接，可以查看該語句本身的AAS統計結果。
單擊執行計劃列的分析，可以查看SQL語句的執行計劃，以及自治服務分析后給出的性能優化參考建議。
以上建議是基于常規的優化策略，對于結構較為簡單的SQL語句來說，效果會比較好，但對于復雜的SQL語句，建議您在參考以上優化建議的基礎上，對執行計劃的信息進行具體的分析并做實際測試驗證。
關于AAS的更多介紹，請參見性能洞察。
分析Top SQL
原因
利用自治服務性能洞察中的AAS功能，可以方便地定位特定時段內導致CPU使用率升高的SQL語句，但是不能提供各類SQL語句的執行頻率、平均CPU開銷、整體CPU資源消耗占比等信息。從優化實例的整體CPU資源效率的角度考慮，獲取CPU資源消耗Top SQL語句的詳細統計信息是很有必要的。
分析
SQL Server支持自動匯總統計SQL語句和存儲過程等對象的執行信息，并可通過sys.dm_exec_query_stats和sys.dm_exec_procedure_stats等系統視圖直接查看，便于定位各類資源開銷的Top SQL。
說明自治服務性能優化中的TOP SQL、TOP Objects報表，以及Management Studio中自帶的Top query類報表，實際也是基于系統視圖的，使用起來較為方便，但是不如直接查詢系統視圖靈活。
優化參數
SQL Server實例的最大并行度MAXDOP（max degree of parallelism）用于控制單個查詢請求可以同時使用的最大活躍線程數（也即CPU核數）。對于CPU開銷較高的SQL語句，如果使用并行度較高的執行計劃，執行時間可能會顯著縮短，但也意味著單位時間內的CPU資源消耗會明顯增加。因此設置最大并行度需要在執行速度和CPU使用率之間進行平衡，建議如下：
查詢請求的并發量較高，大部分SQL語句的執行開銷較低時，MAXDOP的值應小一些，甚至為1（即完全無并行）。
查詢請求的并發量較低，同時存在一些執行開銷較高的SQL語句，MAXDOP的值應大一些，建議不超過實例可使用的最大CPU核數的1/2或1/4。
MAXDOP的默認值為2，是一個相對平衡保守的設置。您可以通過RDS專用的存儲過程sp_rds_configure修改該參數，修改立即生效，無需重啟實例。