阿里雲帳號代開 阿裡雲 RDS CPU 經常達到 100%？慢 SQL 診斷、索引優化與一鍵診斷使用

先看懂 CPU 為什麼會滿

阿里雲 RDS 的 CPU 經常達到 100%，很多人第一反應是升配，但真正的問題通常不在機器太小，而在資料庫把算力浪費在不該做的事上。最常見的來源有三類：慢 SQL、鎖競爭、以及不合理的查詢模式。只要其中一項持續放大，CPU 就會長時間居高不下，最終表現成連線變慢、介面超時、業務堆積，甚至引發連鎖故障。

要處理這類問題，重點不是單純盯著 CPU 使用率，而是先判斷它屬於哪一種型態。若 CPU 在業務高峰時明顯拉升，低峰回落，通常和查詢負載有關；若 CPU 長時間高企且伴隨鎖等待、事務堆積，則更可能是寫入衝突或大事務造成；若 CPU 只有在報表、批次或定時任務執行時暴漲，則要優先排查那幾條 SQL。把問題分類，後面的診斷才不會亂槍打鳥。

先找出真正吃掉 CPU 的 SQL

資料庫 CPU 飆高，十之八九都能在少數幾條 SQL 上找到線索。很多系統表面上請求量很大，但真正拖垮資源的，往往是那些看似不起眼卻反覆執行的查詢。排查時，應先從慢 SQL 入手，而不是急著改配置或擴容。

實務上可以先看阿里雲 RDS 控制台中的性能監控與 SQL 洞察相關資訊，觀察 CPU 高峰期間是否有固定的 SQL 持續出現。若某條 SQL 的執行次數不高，但單次耗時很長，通常是索引、掃描範圍或排序問題；若某條 SQL 執行次數極高，即使單次耗時不長，也可能因為總體累積把 CPU 打滿。這兩種情況的解法完全不同，不能只看平均耗時。

判斷慢 SQL 時，建議關注以下幾個維度：

• 掃描行數是否過大，是否出現全表掃描。
• 返回結果是否遠大於實際需要，是否查了太多欄位。
• 是否存在排序、分組、去重，但缺少相應索引支援。
• 是否在條件中對欄位做了函數運算、隱式轉型或模糊匹配。
• 是否因為鎖等待導致執行時間被拉長。

很多慢 SQL 本質上不是慢在資料庫執行器，而是慢在索引失效後不得不掃大量資料。當查詢資料量被放大數十倍甚至上百倍，CPU 自然會迅速飆升。換句話說，診斷慢 SQL 的目的，不只是找出最慢的語句，而是找出最浪費 CPU 的語句。

從執行計劃看問題出在哪裡

要真正解決 CPU 高企，不能只憑感覺改 SQL，必須看執行計劃。執行計劃能告訴你資料庫是全表掃描、走索引查找、還是先排序再回表。很多看似只差一個條件的 SQL，因為執行計劃不同，資源消耗可能天差地別。

如果發現查詢沒有用到預期索引，先不要急著加新索引，先確認查詢條件是否讓索引失效。例如在欄位上做函數運算、使用不必要的型別轉換、對字串欄位做前置模糊匹配，這些都可能讓索引失去效果。另一個常見問題是複合索引順序不合理，導致只用到了前綴部分，後面的欄位完全發揮不了作用。

執行計劃中的幾個訊號尤其值得留意：如果預估行數和實際相差很大，通常代表統計資訊不準或條件選擇性差；如果有明顯的 filesort 或臨時表，說明排序與分組成本偏高；如果查詢回表次數很多，表示索引雖然命中了，但覆蓋率不足，仍然要反覆讀主鍵資料。這些現象都會增加 CPU 消耗。

看執行計劃的核心思路很簡單：讓資料庫做更少的工作。少掃資料、少排序、少回表、少做重複計算，CPU 才能真正降下來。只要抓到這條主線，後面的優化就有方向。

阿里雲帳號代開 索引優化不是越多越好

一談到慢 SQL，很多人就會直接加索引，但索引不是越多越好。索引能加速查詢，也會增加寫入成本、佔用空間，甚至讓優化器更難選擇。真正有效的索引優化，重點在於讓高頻查詢以最小成本命中最合適的索引。

先從最常見的幾種情況說起。第一，等值查詢高頻出現的欄位，適合建立索引，尤其是經常用於過濾、關聯、排序的欄位。第二，範圍查詢常與等值條件搭配使用，複合索引的順序要遵守高選擇性條件優先、等值條件優先的原則。第三，如果查詢常常只取少量欄位，應考慮覆蓋索引，避免回表。

設計複合索引時，不能只看單條 SQL，而要看一組高頻 SQL 的共同模式。很多系統表面上有十幾條相關查詢，實際上可以用兩三個精準的複合索引覆蓋大部分場景。反過來，如果為每條 SQL 都單獨加索引，表面上看查詢更快了，寫入卻會變得越來越重，CPU 也可能因為維護索引而被拖高。

索引優化時，還要注意以下幾點：

• 避免在低選擇性欄位上單獨建索引，例如狀態欄位、布爾欄位，除非它與其他欄位組合使用。
• 避免重複索引，功能相近的索引要合併評估。
• 對排序和分組常用欄位，考慮把索引順序與查詢順序對齊。
• 阿里雲帳號代開 對超大表，先評估索引建立與重建的窗口，避免在線上高峰期造成額外壓力。

索引調整後，不能只看查詢變快沒有，還要看 CPU 是否真的下降。如果查詢延遲下降，但 CPU 反而更高，說明索引可能把更多查詢推進了主庫，或者讓寫入成本過重。優化的目標不是單點最優，而是整體最優。

慢 SQL 診斷的實用流程

阿里雲帳號代開 面對 RDS CPU 100%，最有效的方法是建立固定流程。這樣不管是臨時故障，還是長期性能問題，都能快速定位。可以把流程簡化成四步：看趨勢、找 SQL、看執行計劃、做驗證。

第一步，看趨勢。先確認 CPU 是持續高位、週期性高峰，還是瞬間尖刺。持續高位通常意味著慢 SQL 或鎖競爭長時間存在；週期性高峰常見於報表、批次任務或定時同步；瞬間尖刺則可能是流量突增或突發大查詢。不同趨勢對應不同處理方式。

第二步，找 SQL。優先從慢查詢日誌、性能洞察、Top SQL 等資訊中找出高耗時、高頻次、高掃描量的語句。不要只看最慢的那條，也要看總消耗最高的那幾條。實戰中，真正造成 CPU 壓力的往往是執行頻率高的中等慢查詢，而不是偶爾出現的極慢查詢。

第三步，看執行計劃。確認慢在掃描、排序、回表還是鎖等待。如果是索引失效，就回到 SQL 條件和索引設計；如果是排序或分組成本高，就考慮調整索引順序或改寫查詢；如果是鎖等待，就要檢查事務範圍、更新順序和熱點資料。

第四步，做驗證。任何調整都要在測試環境先驗證，再觀察 CPU、響應時間、鎖等待、IO 讀寫量是否同步改善。只要一項改善、另一項惡化，就表示方案還不完整。資料庫優化最怕的不是改錯，而是沒有回頭驗證。

一鍵診斷怎麼用才不流於形式

阿里雲 RDS 的一鍵診斷很適合在故障初期快速做初篩。它的價值不在於替代人工分析，而在於幫你快速縮小範圍，避免一開始就陷入低效排查。尤其在 CPU 已經接近 100% 的情況下，先用工具把高風險項目掃一遍，往往能省下大量時間。

一鍵診斷通常會從多個層面檢查資料庫健康度，例如資源使用情況、長時間執行的 SQL、鎖等待、連線數、配置風險與存儲壓力。它的好處是把分散的資訊集中起來，讓你迅速知道問題大概落在哪個方向。若診斷結果明確指向某幾條 SQL 或某類資源瓶頸，就能直接進入針對性處理。

使用一鍵診斷時，要注意三件事。第一，不要只看結論，要看明細和證據，例如哪條 SQL 被標記、哪個時間段 CPU 拉升、是否伴隨慢查詢或鎖等待。第二，不要把診斷結果當成終點，它只是起點，還要結合業務背景判斷是否真的影響核心鏈路。第三，診斷後要建立處理閉環，否則問題修完又會反覆出現。

比較實用的做法是把一鍵診斷和人工分析結合起來：先用診斷快速定位，再根據 SQL 和執行計劃做深挖。這樣既能保證速度，也能保證準確度。對於線上故障來說，能先止血再優化，才是最現實的處理方式。

常見的幾種 CPU 飆高場景

不同場景下，RDS CPU 100% 的成因和解法差別很大。先分清場景，再對症下藥，通常能少走很多彎路。

第一種是讀多寫少的業務，常見於查詢介面、列表頁、搜尋功能。這類場景 CPU 高，多半是索引不足、條件設計不合理、分頁方式效率差。尤其是深分頁查詢，如果直接使用大偏移量，資料庫要跳過大量資料，CPU 和 IO 都會被抬高。

第二種是寫入密集型業務，常見於訂單、日誌、消息、狀態流轉。這類場景 CPU 高，往往和事務過長、索引過多、唯一性校驗頻繁、熱點行更新有關。當大量事務同時競爭相同資源時，資料庫不只是忙著寫，還要忙著等鎖、排隊和重試。

第三種是混合型業務，也就是平時查詢和寫入都不少。這種場景最容易被忽略，因為單看某一類指標都不算極端，但疊加後 CPU 很容易被頂滿。混合型業務最重要的是平衡，不要為了某一類 SQL 的極致優化，讓另一類操作付出更高代價。

降低 CPU 壓力的落地做法

如果想把 CPU 從 100% 拉回來，建議先做短期止血，再做中期優化，最後建立長期機制。這樣比較符合線上系統的現實節奏。

短期止血的重點是減少當前壓力。可以先暫停非核心批次任務、降低報表頻率、限制異常流量，必要時對最重的 SQL 做臨時下線或降頻。若是明顯的慢 SQL，先從應用層做臨時改寫，例如縮小查詢範圍、減少返回欄位、取消不必要的排序。

中期優化的重點是治本。包括補齊關鍵索引、重寫低效 SQL、拆分超大事務、清理無用索引、改善分頁方式，以及把高成本查詢從主路徑移出。這一階段要以資料說話，不能只靠經驗判斷。

長期機制則是建立監控和回饋。對 CPU、慢 SQL、鎖等待、連線數、IO、緩存命中率建立持續監控，並設置明確告警閾值。最好還能把每次故障的慢 SQL、執行計劃、索引調整和效果寫成內部記錄，久而久之就會形成團隊自己的資料庫優化方法論。

不要忽略業務與資料庫的配合

很多 CPU 問題看似是資料庫問題，實際上根源在應用層。比如查詢接口過度依賴即時聚合，導致每次請求都現算；又比如前端頻繁刷新、列表每次都拉全量資料，讓資料庫在高峰期承受了不必要的壓力。只從資料庫端修補，往往只能治標。

更合理的做法，是把資料庫、應用、緩存和任務系統一起看。能在緩存層解決的，就不要每次都打到 RDS；能在離線任務中預計算的，就不要讓線上查詢即時計算；能用增量同步解決的，就不要重複掃全表。資料庫不是萬能計算引擎，它最擅長的是穩定地處理合適的查詢。

當 RDS CPU 經常達到 100%，真正值得關注的不是數字本身，而是這個數字背後暴露出的設計問題。是 SQL 寫法不夠好，還是索引設計不對，抑或是業務模型本來就不適合直接壓在資料庫上。把這些問題拆開，答案通常就清楚了。

結語

阿里雲 RDS CPU 經常飆高，表面上是資源緊張，實際上多半是查詢與資料結構的問題。處理這類故障，最重要的是先定位慢 SQL，再看執行計劃，接著優化索引和查詢方式，最後用一鍵診斷和持續監控把結果固化下來。只要方法正確，CPU 100% 並不是無解難題，而是一次把資料庫性能基礎打牢的機會。