當CPU使用率較高或CPU使用率激增時，可能會影響查詢效能，導致業務響應變慢。本文介紹如何查看RDS SQL Server執行個體的CPU使用方式，並提供排查高CPU使用率問題的方法。
查看CPU使用方式
您可以在RDS管理主控台查看RDS SQL Server執行個體的CPU使用方式。
方法一：通過監控與警示查看
訪問RDS執行個體詳情頁的監控與報警頁面，在標準監控頁簽下查看CPU使用率資訊。
方法二：通過自治服務查看
不支援RDS SQL Server 2008 R2雲端硬碟版執行個體。
執行個體所在地區目前僅支援：華東1（杭州）、華東2（上海）、華北1（青島）、華北2（北京）、華北3（張家口）、華北5（呼和浩特）、華北6（烏蘭察布）、華南1（深圳）、華南2（河源）、華南3（廣州）、西南1（成都）、中國（香港）、新加坡、阿聯酋（杜拜）。
訪問RDS執行個體詳情頁的自治服務（原CloudDBA） > 性能優化頁面，在性能洞察頁簽下查看CPU使用率資訊。
分析效能指標
產生原因
對於突發的CPU使用率明顯增高情況，常見原因有如下幾種：
資料庫查詢請求數量突然增加。例如業務負載驟增，或資料快取服務層出現緩衝穿透等。
查詢請求的開銷突然增加。例如應用中出現新的低效查詢請求，或某些查詢語句的執行計畫發生了改變等。
查詢語句的執行計畫編譯頻率明顯增加。例如當執行個體的緩衝壓力增大時，執行計畫緩衝的數量和命中率會顯著下降，將導致資料庫無法重用已有的執行計畫，從而需要頻繁地重新編譯查詢語句的執行計畫，增加系統整體的開銷。
參數嗅探（Parameter Sniffing）導致的CPU高，當多數負載使用的已緩衝執行計畫並非最優時，就會出現這種情況。
分析問題
訪問RDS執行個體詳情頁的自治服務（原CloudDBA） > 性能優化頁面，在性能洞察頁簽下重點關注如下效能指標，以判斷CPU使用率增高的原因。
由於頁面最多僅展示8類指標，若您找不到下文指標，請單擊性能洞察頁面右上方的自訂指標，在彈出的全量指標頁面中，通過調整下方捲軸，篩選目標指標。
指標名稱 | 分析原因 | |
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，如果這些效能指標的值下降也很明顯，則很可能是執行個體的緩衝壓力過大。提高執行個體的記憶體規格是較有效解決方案，您可以通過變更配置來變更執行個體規格。更多詳情，請參見RDS SQL Server主執行個體規格列表。 |
|
參考案例
以下為一個實際的參考案例。
從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資源效率，擷取這些資源消耗最高的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密集型查詢，適當提高並行度可縮短執行時間，但會佔用更多系統調度資源並可能引發並發爭用。配置時需權衡查詢回應時間與系統整體輸送量，建議遵循以下原則：
高並發情境（如OLTP系統）
當系統需處理大量並發請求且多數查詢執行時間較短（<5秒）時，建議設定
MAXDOP≤4，若存在高頻索引操作或分區表掃描，可針對性設定MAXDOP=1以規避並行計劃開銷。低並發情境（如OLAP/報表系統）
對單條複雜查詢（如巨量資料彙總、星型串連）可提升並行度，推薦值
MAXDOP=min（（邏輯CPU數/並發查詢數），8），請遵循微軟官方建議最大不超過邏輯CPU的75%（如64核系統建議≤48）。
RDS SQL Server執行個體的預設值為MAXDOP=2，此配置平衡了並行效率與資源爭用風險，您可以通過 EXECUTE sp_rds_configure 'max degree of parallelism', <value> 實現該參數的動態修改，但需注意修改後需監控CXPACKET等待類型和Scheduler Busy%（SQL Server調度器用於處理任務的時間佔比），建議配合cost threshold for parallelism（預設為5）共同最佳化。