解決 MySQL 5.x+ 空閒連線自動斷開導致應用重連失敗：wait_timeout 配置與連線池驗證最佳實踐

問題現象

MySQL 5.x 預設 wait_timeout=28800（8 小時）。連線空閒超過此值，Server 主動斷開。應用端連線池若無驗證機制，再次借用該連線時拋出 Communications link failure 或 MySQL server has gone away，導致業務報錯。

三種解決方案（按推薦度排序）

方案一：連線池啟用驗證查詢（標準做法，無需改動 DB）

同時設定 testOnBorrow=true、testWhileIdle=true、timeBetweenEvictionRunsMillis=30000，確保借用前、空閒檢查時均驗證連線有效性。

方案二：調大 MySQL wait_timeout（治標，配合方案一雙重保險）

[mysqld]
wait_timeout=604800          # 7 天
interactive_timeout=604800
# 或啟動參數
mysqld --wait_timeout=604800

修改後 SHOW VARIABLES LIKE 'wait_timeout'; 驗證生效。注意：過長會導致殭屍連線佔用 max_connections，需配合方案一清理。

方案三：降級 MySQL 4.0/4.1（不推薦，失去新特性、安全更新）

僅在極舊系統無法升級連線池、無法修改 DB 參數時作為臨時彌補。

定時重啟 MySQL（不推薦常態化）

若必須重啟，請在業務低峰期（如 03:00），並確保：

1. 應用端配置重試機制（指數退避）
2. 讀寫分離架構下優先重啟從庫，主庫最後
3. 重啟前 FLUSH LOGS、SET GLOBAL innodb_fast_shutdown=1

驗證與監控

-- 確認當前 wait_timeout
SHOW VARIABLES LIKE 'wait_timeout';

-- 監控 Aborted_clients / Aborted_connects
SHOW GLOBAL STATUS LIKE 'Aborted_%';
-- 持續增長說明連線異常斷開頻繁

結語

**根治之道在應用層：連線池必須驗證連線有效性**。wait_timeout 僅是輔助緩衝。將 validationQuery=SELECT 1、testOnBorrow=true 納入基礎設施代碼（IaC）標準模板，新專案上線即合規，徹底消除「空閒一夜、早晨業務崩潰」的經典事故。