MySQL 連線管理直接影響系統吞吐量與穩定度。本文系統梳理 7 個核心連線參數，結合實戰場景給出調優建議，並說明應用端連線池配置最佳實踐。
| 參數 | 預設值 | 建議值 | 作用與調優要點 |
|---|---|---|---|
max_connections | 151 | 500~2000 | 最大同時連線數。 監控指標： Max_used_connections / max_connections > 80% 需調大。每連線消耗 sort_buffer_size + join_buffer_size + read_buffer_size 等記憶體，總記憶體 = global_buffers + max_connections * thread_buffers，勿超過物理記憶體 70%。 |
wait_timeoutinteractive_timeout | 28800 (8h) | 120~300 | 非互動/互動連線閒置超時秒數。 應用端連線池 idleTimeout **必須小於** 此值，否則連線池拿到的連線在 MySQL 端已被斷開，導致「Communications link failure」。建議：MySQL 設 300，連線池 idleTimeout 設 60~120 秒。 |
skip-name-resolve | OFF | ON | 關閉 DNS 反向解析。 啟用後連線字串**只能用 IP**，不能用 localhost（需改 127.0.0.1）。顯著降低新連線建立延遲，尤其在 DNS 不穩定環境。 |
max_connect_errors | 100 | 1000000 | 同一主機連續連線失敗達此值則封禁。 設大避免誤封，解封指令： FLUSH HOSTS;。 |
max_allowed_packet | 16M | 64M~256M | 單次封包大小上限。 大欄位、批次 INSERT、長 SQL 需調大。 客戶端也需同步設定（JDBC maxAllowedPacket、Python max_allowed_packet）。 |
thread_concurrency | 10 | CPU 核心數 × 2 | 舊版參數（5.5+ 棄用，改由 OS 調度）。 現代版本關注 innodb_thread_concurrency（預設 0=無限），高併發可設為 CPU核心數 × 2 限制 InnoDB 內部並發執行緒，減少上下文切換。 |
back_log | 50 | 500~1000 | 監聽隊列長度。 當連線爆發時，新連線排隊等待的緩衝區。 若 SHOW PROCESSLIST 出現大量 unauthenticated user，需調大。受 OS somaxconn 限制（sysctl -w net.core.somaxconn=1024）。 |
# 查看當前連線狀態
SHOW PROCESSLIST;
SHOW FULL PROCESSLIST;
# 統計連線狀態分佈
SELECT `Command`, COUNT(*) AS cnt FROM information_schema.PROCESSLIST GROUP BY `Command`;
# 典型輸出：
# Sleep 200 <-- 閒置連線過多，檢查連線池配置
# Query 50
# Locked 5| 框架/池 | 核心參數 | 推薦值 | 關鍵原則 |
|---|---|---|---|
| HikariCP (Spring Boot 預設) | maximumPoolSize |
CPU 核心數 × 2 + 1 | 公式：connections = ((core_count * 2) + effective_spindle_count)。資料庫端 max_connections ≥ 所有服務實例 maximumPoolSize 之和 + 50（保留管理連線）。 |
minimumIdle |
= maximumPoolSize | 生產環境建議固定大小，避免擴縮容抖動。 | |
idleTimeout |
60000 (60s) | 必須 < MySQL wait_timeout。 | |
maxLifetime |
1800000 (30min) | 強制回收長連線，防止 MySQL 端參數變更不生效。 | |
connectionTimeout |
30000 (30s) | 獲取連線超時。 | |
| Druid | maxActive, minIdle |
同 HikariCP | validationQuery: SELECT 1, testWhileIdle: true, timeBetweenEvictionRunsMillis: 60000。 |
| DBCP2 | maxTotal, maxIdle |
同 HikariCP | 較舊，效能不如 HikariCP，建議遷移。 |
| 現象 | 可能原因 | 解決方向 |
|---|---|---|
| Too many connections | 連線池總和 > max_connections；連線洩漏未關閉 | 調大 max_connections；檢查應用 finally 區塊關閉連線；啟用連線池洩漏偵測 |
| Communications link failure / Connection reset | MySQL 端 wait_timeout 斷開閒置連線，連線池未驗證直接使用 | 縮短連線池 idleTimeout；開啟 testWhileIdle / validationQuery |
| 新連線建立極慢 | DNS 反向解析超時 | 開啟 skip-name-resolve；檢查 /etc/hosts |
| Packet too large | SQL/欄位超過 max_allowed_packet | 調大 max_allowed_packet（客戶端+伺服器） |
| Host 'x.x.x.x' is blocked | 連線錯誤次數超過 max_connect_errors | FLUSH HOSTS；調大 max_connect_errors；排查網路/認證問題 |
Threads_connected / max_connections 使用率（目標 < 80%）Aborted_connects 異常中斷計數Connection_errors_internal 內部錯誤ActiveConnections, IdleConnections, PendingThreads
