MySQL 空閒連接自動斷開導致應用重連失敗：wait_timeout 調優與應用層連接池配置

MySQL 默認 wait_timeout=28800（8 小時），空閒連接超時被服務器主動斷開。應用層連接池若無驗證/重連機制，再次使用該連接會報錯 Communications link failure / MySQL server has gone away。本文給出服務端調大超時、應用端連接池驗證、雙向保障方案。

一、問題根因

• MySQL 5.x 某版本後修改：空閒超時連接的重連請求（Reconnect）被拒絕，必須建立新連接
• 應用連接池（DBCP、HikariCP、Druid、c3p0 等）借用連接時若無「驗證查詢」，直接使用已斷開的舊連接 → 報錯

二、服務端方案：調大 wait_timeout

# /etc/my.cnf
[mysqld]
wait_timeout = 500000          # 約 5.8 天
interactive_timeout = 500000   # 交互式客戶端超時

# 或啟動參數
mysqld --wait_timeout=500000 --interactive_timeout=500000

修改後重啟驗證：

mysql> SHOW VARIABLES LIKE 'wait_timeout';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| wait_timeout  | 500000 |
+---------------+--------+

⚠️ 僅調大超時**治標不治本**，長時間空閒連接佔用服務器資源（線程、內存），極端情況導致 Too many connections。

三、應用端方案：連接池驗證機制（根治）

四、雙向保障最佳實踐

1. 服務端：wait_timeout = 86400（1 天），足覆蓋夜間低峰，避免無限堆積
2. 應用端：連接池**必開**空閒檢測（testWhileIdle=true / idleConnectionTestPeriod）+ **借用時驗證**（testOnBorrow=true / HikariCP 依賴 isValid()）
3. 驗證查詢：SELECT 1（極輕量、無副作用）
4. 連接生命週期：maxLifetime < wait_timeout（HikariCP maxLifetime 默認 30 分鐘），主動回收老化連接

五、代碼層面重試模式（兜底）

// 伪代碼：數據庫操作統一捕獲通信異常，重試一次
try {
  return dao.query(sql);
} catch (CommunicationsException | SQLException e) {
  if (isConnectionFailure(e)) {
    log.warn("DB connection lost, retry once");
    return dao.query(sql);  // 連接池會提供新連接
  }
  throw e;
}

「服務端給足緩衝、應用端主動驗證、代碼層兜底重試」三層防線，徹底解決空閒連接斷開導致的業務報錯。