問題原因

應用提交查詢操作或數據修改操作時，系統需要執行大量的邏輯讀操作，其中邏輯IO包含執行查詢所需訪問表的數據行數。所以系統需要消耗大量的CPU資源以維護從存儲系統讀取到內存中的數據一致性。

說明：
大量行鎖沖突、行鎖等待或后臺任務也有可能會導致實例的CPU使用率過高，但這些情況出現的概率非常低，本文不做討論。

解決方案

對于因應用負載高導致CPU使用率高的狀況，使用SQL進行優化的余地不大，建議您從應用架構、實例規格等方面來處理問題。

• 升級實例規格，增加CPU資源。
• 增加只讀實例，將對數據一致性不敏感的查詢（比如商品種類查詢、列車車次查詢）轉移到只讀實例上，分擔主實例壓力，詳情請參見讀寫分離。
• 使用億速云云數據庫Memcache或者云數據庫Redis，盡量從緩存中獲取常用的查詢結果，減輕RDS實例的壓力。
• 定期歸檔歷史數據、采用分庫分表或者分區的方式減小查詢訪問的數據量。盡量優化查詢，減少查詢的執行成本，提高應用可擴展性。

更多信息

系統資源算法

下文通過一個簡化的模型來說明系統資源、語句執行成本以及QPS（Query Per Second 每秒執行的查詢數）之間的關系。

• 條件：應用模型恒定，即應用沒有修改。
• avg_lgc_io：執行每條查詢需要的平均邏輯IO。
• total_lgc_io：實例的CPU資源在單位時間內能夠處理的邏輯IO總量。
• 關系公式：total_lgc_io = avg_lgc_io × QPS即單位時間CPU資源 = 查詢執行的平均成本 × 單位時間執行的查詢數量。

避免出現CPU使用率達到100%的原則

• 設置CPU使用率告警，實例CPU使用率保證一定的冗余度。
• 應用設計和開發過程中，要考慮查詢的優化，遵守MySQL優化的一般優化原則，降低查詢的邏輯IO，提高應用可擴展性。
• 新功能、新模塊上線前，要使用生產環境數據進行壓力測試。
• 新功能、新模塊上線前，建議使用生產環境數據進行回歸測試。