解決 MySQL "Too many connections" 連線數耗盡的系統級方案

錯誤本質：連線池洩漏 vs 配置不足

報錯 ERROR 1040 (HY000): Too many connections 時，實際觸發條件為：

threads_connected >= max_connections

兩大根因：

1. 應用層洩漏：未正確關閉連線、連線池配置錯誤、長事務佔用。
2. 配置過保守：預設 max_connections=151 (5.7+) / 100 (舊版) 遠低於現代並發需求。

即時診斷儀表板

-- 當前連線數
SHOW STATUS LIKE 'Threads_connected';

-- 歷史峰值
SHOW STATUS LIKE 'Max_used_connections';

-- 配置上限
SHOW VARIABLES LIKE 'max_connections';

-- 詳細連線來源
SHOW PROCESSLIST;
-- 或
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';

分層解決策略

層級 1：緊急擴容 (秒級生效，無需重啟)

SET GLOBAL max_connections = 5000;  -- 視記憶體而定，建議 ≤ 10000

持久化需同步修改 my.cnf：

[mysqld]
max_connections = 5000

層級 2：配套參數同步調優 (必須跟上，否則 OOM)

層級 3：應用層根治 (治本)

• 連線池サイジング：pool_size = (CPU核心數 * 2) + 有效磁碟數，不可無限增大。
• 強制回收：啟用 wait_timeout=300、interactive_timeout=300 清理閒置連線。
• 代碼審計：所有執行路徑必須 try-finally / using 關閉連線；異常拋出前釋放資源。
• 監控告警：Prometheus 監控 mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.8 觸發告警。

常見誤區

「把 max_connections 設成 10 萬就萬事大吉」

❌ 每個連線佔用 thread_stack (256KB) + sort_buffer/join_buffer/read_buffer 等執行緒緩衝，10 萬連線需數十 GB 記憶體，極易觸發 OOM Killer。實際上限受限於 open_files_limit 與 OS 文件描述符，通常 1-2 萬為物理極限。

總結

「配置給上限，應用守底線，監控拉警報」 三管齊下。先用 SET GLOBAL 救火，再調優參數矩陣，最後在代碼層徹底堵住洩漏，才是持久之計。