MySQL「Out of memory」錯誤排查與參數優化實戰 (32 位系統記憶體限制)

錯誤現象

錯誤日誌出現 mysqld-nt: Out of memory (Needed 1677720 bytes)，網站變慢甚至服務不可用。伺服器物理記憶體 32GB，但運行 32 位作業系統與 32 位 MySQL。

根本原因分析

1. 32 位系統進程地址空間限制

32 位進程最大可定址 4GB 虛擬記憶體，Linux 核心預設分配 3GB 給用戶空間，1GB 給核心空間。即便物理記憶體 32GB，單一 MySQL 進程也**無法使用超過 3GB** 記憶體。若配置參數總和超過此限制，即觸發 OOM。

2. 關鍵記憶體參數公式

MySQL 總記憶體佔用估算公式：

總記憶體 ≈ key_buffer_size
  + (read_buffer_size + sort_buffer_size + read_rnd_buffer_size + join_buffer_size) * max_connections
  + innodb_buffer_pool_size
  + innodb_log_buffer_size
  + innodb_additional_mem_pool_size
  + max_heap_table_size / tmp_table_size (較大者)
  + thread_stack * max_connections
  + 其他固定開銷

核心原則： 此總和必須 小於 3GB (約 3,000MB)。

實戰排查與調優步驟

步驟 1：檢視當前配置

SHOW VARIABLES LIKE '%buffer%';
SHOW VARIABLES LIKE '%heap%';
SHOW VARIABLES LIKE '%tmp_table%';
SHOW VARIABLES LIKE 'max_connections';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

步驟 2：識別超標參數 (案例實測)

步驟 3：驗證調整效果

修改 my.cnf 後重啟 MySQL，持續監控 5+ 小時，錯誤日誌不再出現 Out of memory，服務穩定運行。

核心參數配置建議 (32 位系統、3GB 記憶體上限場景)

[mysqld]
# 全局緩衝
key_buffer_size = 128M
innodb_buffer_pool_size = 1G
innodb_log_buffer_size = 64M
max_heap_table_size = 128M
tmp_table_size = 128M

# 每連線緩衝 (謹慎設定，乘以 max_connections)
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 4M
join_buffer_size = 2M
thread_stack = 256K

# 連線控制
max_connections = 500
thread_cache_size = 50

# 其他
query_cache_size = 0          # 高並發建議關閉 QC
query_cache_type = 0
table_open_cache = 2048
table_definition_cache = 2048

附錄：PHP 「Fatal error: Out of memory」同理可證

若 PHP 報錯 Fatal error: Out of memory (allocated 262144) (tried to allocate 19456 bytes)，同屬 32 位進程記憶體耗盡。解決：修改 php.ini 提高 memory_limit (如 128M 或 256M)，並重啟 Apache/PHP-FPM。但根本上應排查 PHP 程式碼記憶體洩漏或單腳本過度消耗。

總結

1. 32 位系統硬傷：單進程 3GB 上限是物理限制，參數總和不可超標。
2. 每連線緩衝是隱形殺手：sort_buffer_size、read_buffer_size、join_buffer_size 乘以 max_connections 才是真實佔用。
3. 遷移 64 位是終極方案：CentOS 7 / Ubuntu 18.04+ + 64 位 MySQL 可徹底解決記憶體瓶頸，支援超大 innodb_buffer_pool_size 發揮 SSD/大記憶體優勢。