CPU使用率較高時，容易影響查詢效能。本文介紹如何查看CPU使用方式以及排查CPU問題。
查看CPU使用方式
RDS管理主控台提供多種查看CPU使用方式的方法：
監控與警示
在控制台的監控與報警頁面，單擊頁簽，在資源監控內，可以查看CPU使用率資訊。
自治服務
執行個體不能是RDS SQL Server 2008 R2雲端硬碟版。
在控制台的自治服務（原CloudDBA） > 性能優化頁面，單擊頁簽，可以查看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使用率升高，但也會有些查詢語句的執行開銷很高而邏輯讀開銷並不高，這時要分析對應時段內的查詢語句以定位原因。
分析活動會話
原因
導致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修改該參數，修改立即生效，無需重啟執行個體。