MySQL 預設 max_connections = 151（5.7+），許多中小站點維持默認值，導致流量高峰出現 Too many connections；也有盲目調大到 10000 導致 OOM 的教訓。本文闡述動態調整方法、容量規劃公式、監控指標與安全上限建議。

動態調整（無需重啟）

-- 登入 MySQL
mysql -uroot -p

-- 臨時生效（重啟失效）
SET GLOBAL max_connections = 3000;

-- 永久生效（需寫入配置文件）
-- 編輯 /etc/my.cnf
[mysqld]
max_connections = 3000

關聯參數同步調大

容量規劃公式：安全上限怎麼算？

可用記憶體 = 物理內存 - OS預留(1-2GB) - InnoDB Buffer Pool - 其他進程
會話記憶體 = read_buffer + sort_buffer + join_buffer + thread_stack + ...
           ≈ 16M + 16M + 16M + 0.5M ≈ 50MB/連接 (保守估算)
安全最大連接數 = 可用記憶體 / 會話記憶體 * 0.8 (安全係數)

例：16GB 內存，Buffer Pool 10GB，OS 2GB → 可用 4GB
安全上限 ≈ 4GB / 50MB * 0.8 ≈ 65 連接
→ 若需 3000 連接，必須升級內存或啟用連接池（ProxySQL/HikariCP）複用！

監控與報警儀表盤

-- 當前連接數
SHOW STATUS LIKE 'Threads_connected';
-- 歷史峰值
SHOW STATUS LIKE 'Max_used_connections';
-- 連接使用率
Max_used_connections / max_connections * 100%

-- 慢查詢中等待鎖/連接的
SHOW PROCESSLIST;
-- 或
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';

報警閾值建議： 連接使用率 > 70% 報警，> 85% 緊急擴容或限流。

最佳實踐：連接池才是正解

• 應用層配置連接池（HikariCP/Druid/Pool），maximumPoolSize 遠小於 max_connections。
• ProxySQL 做連接多路複用，後端 MySQL max_connections 只需幾百。
• 禁用長連接，設置 wait_timeout=300、interactive_timeout=300 釋放空閒連接。

調大 max_connections 只是止血，連接池複用才是治本。請按「可用記憶體 / 單連接記憶體」科學設定上限，配合連接池與監控報警，構建穩健的連接管理體系。