MySQL 服務器內存使用深度解析：從理論公式到實戰監控

為什麼要關注 MySQL 內存使用？

配置 MySQL 服務器時，如何估算內存消耗是許多 DBA 和開發人員常問的問題。關心內存使用的原因很直觀：若配置過少，服務器性能將無法發揮最優；若配置過多，則可能導致服務器崩潰、查詢無法執行，或因交換而嚴重拖慢速度。在 32 位平台上，甚至還會面臨地址空間耗盡的風險。

「秘密公式」為何不可靠？

雖然大家都想找到一個精確的計算公式，但這在現代 MySQL 版本中並不現實。原因有二：

• 公式極其複雜：隨著版本迭代，內存分配邏輯變得愈發繁雜。
• 理論值與實際值脫節：計算出的「理論最大值」往往與實際消耗相差極大。例如一台 8GB 內存的服務器，理論最大值可能高達 100GB 以上。且不存在通用的「超額係數」，實際使用率可能只有理論值的 1%~10%，高度依賴應用場景與配置。

實戰估算方法：全局緩衝 + 線程緩衝

1. 啟動時固定分配的全局緩衝

這些內存在 MySQL 啟動時即分配，且常駐內存：

• key_buffer_size（MyISAM 索引緩衝）
• innodb_buffer_pool_size（InnoDB 數據與索引緩衝，通常佔最大頭）
• innodb_additional_mem_pool_size（InnoDB 內部數據字典）
• innodb_log_buffer_size（InnoDB 重做日志緩衝）
• query_cache_size（查詢緩存，MySQL 8.0 已移除）

若大量使用 MyISAM，還需預留作業系統文件緩存空間。加上作業系統、其他應用程式所需內存，再預留約 32MB 給 MySQL 核心代碼與靜態緩衝，即可得到啟動基礎內存佔用。

2. 連線相關的線程緩衝

每個連線會分配專屬緩衝：

• 基礎分配：約 256KB（線程棧、網絡緩衝等），即便閒置也會佔用。
• 事務開啟：需額外空間。
• 複雜查詢：全表掃描、排序、臨時表等操作會動態分配 read_buffer_size、sort_buffer_size、read_rnd_buffer_size、tmp_table_size 等，用完即釋放。
• 特殊操作：批量插入、ALTER/OPTIMIZE/REPAIR TABLE 等會分配更大緩衝。

關鍵洞見：OLTP 簡單查詢場景下，默認緩衝下每線程通常 < 1MB。盲目調大 sort_buffer_size 等參數反而可能因內存管理開銷導致性能下降。

替代策略：監控實際峰值內存

與其追求理論公式，不如直接監控生產環境實際內存使用：

1. 計算作業系統、文件緩存、其他應用所需內存。
2. 32 位環境下限制 mysqld 虛擬內存約 2.5GB。
3. 使用 ps aux 觀察 VSZ（虛擬內存） 變化趨勢，而非 Resident Memory（受 swap 影響大）。
4. 根據實際峰值調整參數，而非理論計算。

那些容易被忽略的內存消耗者

即便監控了基礎參數，以下因素仍可能導致內存超預期：

• 子查詢多層物化：每層可能獨立分配 read_buffer、sort_buffer、tmp_table_size。
• 會話級變量覆蓋：開發者可在會話中修改緩衝大小，全局配置失效。
• 多 Key Cache：可創建多個索引緩存。
• 查詢解析/優化器：極複雜查詢解析階段可能消耗大量內存。
• 存儲過程、Prepared Statement、Cursor：單連線可持有大量對象，各自佔用內存。
• InnoDB 表緩存：存儲表元數據，從不清理，大量表時佔用可觀，甚至允許擁有 CREATE TABLE 權限的用戶耗盡內存。
• MyISAM 記錄緩衝：持有至表關閉，大小等於表中最大記錄長度。
• FEDERATED 引擎：遠程查詢結果集可能無界限佔用內存。
• Blob 處理：可能需 3 倍內存（如 256MB Blob 需 768MB）。
• 第三方存儲引擎：可能有獨立的全局/線程級內存分配，不受標準參數控制。

總結與建議

MySQL 內存消耗極其動態且場景相關，試圖計算「絕對峰值」不切實際。最佳實踐是：

1. 基於全局緩衝 + 預估併發連接數做初步規劃。
2. 生產環境持續監控 VSZ 實際走勢。
3. 通過壓測觀察調整參數（如 sort_buffer_size 從 1MB 增至 4MB，1000 連接下峰值可能僅增 30MB 而非理論 3000MB）的實際影響。
4. 接受「無法 100% 保證不 OOM」的現實，重點防範明顯風險點。