過去幾天我們已經達到 IOP 的上限了。我們幾次配置了更多的 IOPS。 1250 -> 2500 -> 4500 我們很快就發現每個步驟都在使用所有可用的 IOPS，因為它會在讀取和寫入之間達到最大值。
今天早上，我們終於迎來了另一個大客戶，我們的 CPU、記憶體和 IOPS 都達到了極限。我決定提供更大的資料庫類型以保持系統運作。我們從 db.m5.xlarge 變成 db.m5.2xlarge。透過升級，我們也將 IOP 提高到 8000。
相比之下，現在我們的 CPU 受到了重創，我們的 IOPS 應用程式似乎響應良好，但我們的任務隊列非常慢。
程式碼沒有改變，只是資料庫改變了。我缺什麼？ RDS 報告不正確嗎？
您會注意到過去 3 天內讀取 IOPS 的跳躍，這些與更高的 IOPS 規定相一致。
答案1
您可能有一個從懸崖上掉下來的查詢。 （感謝您的精彩描述。這是可能的解釋。）
一個例子。假設一個查詢正在掃描一個包含 70M 行的 7GB 表（沒有有用的索引等）。
情況1：RAM=8GB；innodb_buffer_pool_size= 6GB。該查詢將所有內容從快取中取出以完成掃描。這需要可靠的 I/O。所有其他查詢也會受到影響——它們的資料也從 RAM 中刪除。
情況2：RAM=16GB；innodb_buffer_pool_size= 12GB。第一次掃描將整個表載入到快取中；該查詢的後續運作不需要執行任何 I/O。由於不存在快取爭用，甚至其他查詢也運行得更快。
在這兩種情況下，在查看所有 70M 行時可能會消耗大量 CPU 資源。
A 方案：花錢買更多 RAM、CPU 和不需要的 IOP。
B 計畫：找到那個非常頑皮的查詢並讓我們幫忙優化它。然後你可以回到更便宜的虛擬機器。
請提供查詢以及SHOW CREATE TABLE所涉及的表。解決方案可能就像添加複合索引或重新制定查詢一樣簡單。
答案2
這裡的關鍵是什麼都不做。 「神奇地」我們的 CPU 正常化到了我預期的水平。好消息是我發現了查詢中的幾個痛點、一些過度熱心的鎖，以及對調優 InnoDB/RDS/MySQL 的大量了解。
也許 RDS 正在慢慢優化索引或我不完全理解的東西，但現在我們的延遲非常驚人，吞吐量和使用率完全符合我對 4 個以上核心和 2 倍內存的預期。
