AWS國際帳號購買 AWS 資料庫 CPU 飆高排查步驟
一、先確認 CPU 飆高是不是「真的異常」
看到 AWS 資料庫 CPU 衝上去，第一反應通常是系統出事了，但先別急著下結論。CPU 升高本身不等於故障，有時只是流量短暫增加、批次作業集中執行，或是應用程式剛好在做大量查詢。真正要判斷的是，這個上升是否超出平常波動範圍，是否伴隨延遲變長、連線數暴增、I/O 卡住或錯誤率提高。
排查的第一步，是把「時間點」釘住。先看 CloudWatch 上 CPU 利用率開始拉高的具體時間，再對照那段時間前後的請求量、部署紀錄、排程任務、資料匯入匯出、索引變更與參數調整。很多問題不是從 CPU 開始，而是從某個變更開始，只是最後先反映在 CPU 上。
如果是 Amazon RDS 或 Aurora，還要注意多個指標一起看。單看 CPU 很容易誤判，最好同時觀察 FreeableMemory、ReadIOPS、WriteIOPS、ReadLatency、WriteLatency、DatabaseConnections、Deadlocks、SwapUsage 等指標。CPU 飆高但 I/O 正常，和 CPU 飆高且 I/O 一起升高，背後原因往往完全不同。
二、先看監控圖，找出異常型態
CPU 飆高的型態不同，處理方式也不同。大致可以分成三類：持續高、尖峰型高、週期性高。持續高通常代表有某個查詢或程序長時間吃資源；尖峰型高常見於瞬間流量衝高、批次工作執行，或某個應用程式在短時間內重試大量請求；週期性高則多半和排程、報表、同步任務有關。
看圖時不要只盯著 CPU 曲線，還要把同時段的連線數、查詢數、磁碟讀寫、延遲、鎖等待一起拉出來比對。如果 CPU 高的同時，DatabaseConnections 也明顯增加，通常要先查應用層連線管理與流量入口。如果 CPU 高但 I/O 沒跟著升，常見是查詢計畫不佳、索引失效、排序或聚合成本過高。如果 CPU 高又伴隨等待時間上升，則要懷疑鎖競爭或資料庫內部等待。
三、先從慢查詢下手，因為這是最常見的元兇
資料庫 CPU 飆高，最常見的原因就是慢查詢。不是所有慢查詢都一定跑很久，有些查詢單次執行時間看起來還可以，但被大量重複呼叫後，整體 CPU 仍然會被吃滿。尤其在高併發系統中，少數幾條查詢就足以拖垮整台資料庫。
在 AWS 環境裡，建議優先看 Performance Insights、慢查詢日誌、或資料庫引擎本身提供的查詢統計。要找的不是「最慢的一條」而已，而是「執行次數最多、總耗時最高、平均耗時偏高」的查詢。很多時候真正的問題查詢，並不是最慢，而是跑得太頻繁。
找到可疑 SQL 後，要看它是否存在以下幾種特徵：全表掃描、使用函式導致索引失效、條件寫法不利於索引利用、排序欄位沒有索引、JOIN 條件不精準、子查詢過深、回傳欄位過多。這些問題未必會讓單次查詢慢到離譜，但在高流量下會迅速放大 CPU 壓力。
先看執行計畫，不要只憑感覺改 SQL
很多人一看到慢查詢就急著改語法，但真正有效的方法是先看執行計畫。執行計畫能告訴你資料庫是走索引、全表掃描，還是做了大量排序與臨時表操作。若計畫顯示掃描筆數遠大於預期，通常代表索引沒有被正確利用，或者條件選擇性太差。
改 SQL 的方向通常有幾個：把可用索引的條件前置、避免在欄位上套函式、減少不必要的欄位回傳、拆分過大的查詢、把高成本查詢改成分批處理。若是報表類需求，甚至可以考慮預先彙總、建立物化結果，避免每次都即時計算。
四、檢查索引是否失效或不足
索引問題是 CPU 飆高的第二大常見原因。索引不是越多越好，但索引不夠或設計錯誤，資料庫就只好靠 CPU 硬掃。尤其在資料成長後，早期看似沒問題的查詢，可能因為資料量暴增而開始變慢。
先檢查目標表是否有符合查詢條件的索引，特別是 WHERE、JOIN、ORDER BY 常用到的欄位。若查詢條件包含多個欄位，要注意複合索引的欄位順序是否合理。很多人明明有索引，卻因為順序不對，導致資料庫根本用不上。
也要注意索引過多的副作用。寫入時每個索引都要維護，若系統寫入量大、索引又太多，CPU 也會被更新與維護成本拖高。某些場景下，問題不是少了索引，而是過度索引造成寫入端壓力。排查時要同時看讀寫比例，不能只從讀取優化下手。
五、確認是否發生鎖競爭或交易堵塞
有些 CPU 飆高不是因為查詢太多，而是因為交易卡住後反覆重試、等待與回圈，導致整體資源被耗盡。當資料庫出現鎖競爭，應用程式可能會大量重送請求，讓 CPU 看起來像是被查詢吃滿，實際上是等待與重試放大了壓力。
排查時要看是否有長交易、未提交事務、熱點資料列反覆更新、批次更新與線上交易互相干擾。若某些表被大量更新，又缺少合理索引，鎖範圍會變大，連帶增加等待時間。Aurora MySQL、RDS MySQL、PostgreSQL、SQL Server 都有各自的鎖觀察方式，但核心觀念一樣：找出誰在持有鎖、誰在等待、等待多久。
AWS國際帳號購買 如果資料庫已經出現鎖風暴，先不要急著全面重啟。優先找出長時間持鎖的交易，確認是否可以終止特定會話。重啟雖然看似快，但如果根因還在，服務恢復後很可能再度發生。
六、檢查連線數與連線管理
連線數暴增也是 CPU 飆高常見原因之一。很多應用程式把連線池設定得太大，或在高峰時沒有做好回收，導致資料庫同時要處理大量連線上下文切換。即使每條查詢不重，光是維持過多連線，也會讓 CPU 和記憶體壓力升高。
先觀察 DatabaseConnections 是否異常增加，再回頭看應用端是否有重試風暴、殘留連線、排程服務重複啟動、容器擴縮過快等情況。若是使用中介層或應用伺服器，還要檢查連線池的最大值、閒置回收時間與健康檢查機制。連線池設太小會排隊，設太大會把資料庫壓垮，關鍵是找到符合實際流量的平衡點。
對 Aurora 或 RDS 來說，建議也看一下是否有大量短連線建立與釋放。頻繁建立連線比維持連線更耗 CPU，尤其在高併發 API 場景下特別明顯。若業務允許，應盡量使用長連線池，避免每個請求都重新連庫。
七、確認是否是背景任務、批次作業或維護程序
CPU 飆高不一定來自線上請求，很多時候是背景任務在作怪。像是批次匯入、資料同步、報表生成、統計更新、索引重建、VACUUM、ANALYZE、備份、複寫同步，都可能在特定時間把 CPU 拉高。
尤其是排程任務常常和線上尖峰重疊。白天流量已經高，若再加上夜間未完成的批次任務延後執行，就會出現 CPU 長時間高位運轉。這種情況下，單純加大規格不一定有效，因為問題是任務安排與資源分配，不是硬體不足。
排查時，把所有排程與維護工作列出來，對照 CPU 飆高的時間點。有些雲端服務會自動執行維護動作，也可能在版本升級、參數修改後重跑統計資訊。這類問題很容易被忽略，但卻經常是根因。
八、別忽略資料分布與查詢條件變化
同一條 SQL，今天快不代表明天也快。資料庫效能很大一部分取決於資料分布與查詢條件。當資料量變大、熱點值變集中、某些區間查詢變多，原本正常的計畫可能突然變差，CPU 也就跟著往上衝。
AWS國際帳號購買 例如某個欄位原本分布平均，後來因為業務活動讓特定狀態資料暴增，查詢選擇性就會下降。資料庫估算錯誤時，可能選錯索引或誤判掃描成本，最後導致 CPU 被白白消耗。這類問題不是改一條 SQL 就一定能解，還要回到資料模型與統計資訊更新頻率。
如果近期有大量新資料灌入，或資料刪除後沒有做適當整理，也可能讓統計資訊失真。這時候更新統計資訊、重新分析表分布，常常比盲目擴容更有效。
九、快速止血的方法
當 CPU 已經飆高到影響服務，排查固然重要，但先止血更重要。最直接的方法是先降低壓力來源，例如暫停非必要批次作業、限制高成本報表、調整流量入口、先關閉不必要的重試機制。如果已經找出明確元兇查詢，也可以先從應用層阻擋或改走降級路徑。
必要時可以臨時擴容，但要把它當成應急措施，不是根治方案。升級規格能爭取時間，卻不能解決錯誤 SQL、索引設計不佳、鎖競爭或連線管理不當。若每次 CPU 一高就靠升級撐住，最後只會把成本越拉越高。
若問題出在單一資料表或單一查詢，優先採取局部處理，比整體調整更有效。例如將大查詢拆分、限制查詢時間範圍、加上快取、把同步任務延後、把寫入操作分批提交。能減少即時壓力的手段，才是第一時間該做的事。
十、建立長期預防機制
真正成熟的做法，不是等 CPU 飆高再救火，而是建立預防機制。第一，為重要指標設定告警門檻，不只看 CPU，也要看連線數、延遲、等待事件、錯誤率與 I/O。第二，為慢查詢建立持續觀察機制，定期檢查 Top SQL，避免小問題拖成大事故。第三，所有上線變更都要能追溯，讓你在 CPU 異常時能快速回看變更紀錄。
AWS國際帳號購買 此外，資料庫設計也要跟著業務成長一起調整。索引不是一次建好就永遠不變，表結構也不是上線後就不用再看。當查詢模式改變、資料量成長、服務拆分之後，原本的設計可能不再適用。每隔一段時間做一次效能回顧，遠比事故後補救來得划算。
如果你的系統規模已經不小，建議把排查流程標準化。當 CPU 飆高時，團隊不需要每次都重新想一遍，照著固定步驟看監控、查慢 SQL、看鎖、看連線、看排程、看變更，就能大幅縮短定位時間。這不只是效率問題，更是穩定性問題。
結語：排查的核心是找出「誰在消耗 CPU」
AWS 資料庫 CPU 飆高，表面上看是資源不足，實際上多半是某個查詢、某個流程、某個變更把成本放大了。排查時不要被表象帶走，先確認異常型態，再從慢查詢、索引、鎖競爭、連線管理、背景任務與資料分布逐一縮小範圍。只要順著時間線與指標走，通常都能找到真正的原因。
最重要的是，不要只做一次性處理。把這次事故整理成可複用的排查清單，讓下一次 CPU 再度升高時，團隊能更快反應。資料庫穩不穩，往往不是看它平常有多快，而是看它在高壓下能不能被準確地診斷與修正。
