解決 MySQL 8 小時自動斷開連線問題：連線池配置最佳實踐

專案使用連線池連接 MySQL，閒置超過 8 小時（預設 wait_timeout）後再次使用即報錯。經理不允許修改 MySQL 伺服器配置，且嘗試過 autoReconnect=true、調整 maxIdleTime、定時查詢保活等方案均無效。核心原因在於連線池未驗證取出連線的有效性，導致應用拿到的是已被 MySQL 斷開的「殭屍連線」。

根本解決方案：啟用連線驗證機制

請在連線池配置中加入以下兩個關鍵屬性（以 DBCP/HikariCP 等主流連線池為例）：

• validationQuery：SELECT 1（MySQL 適用）或 SELECT 1 FROM DUAL（Oracle 適用）。連線池會在借出連線前執行此查詢，若失敗則丟棄並重建。
• testOnBorrow：設為 true。表示每次從池中取出連線時都執行 validationQuery 驗證。

配置範例（DBCP）

<property name="validationQuery" value="SELECT 1" />
<property name="testOnBorrow" value="true" />

進階優化：testWhileIdle + timeBetweenEvictionRunsMillis

若不想每次借用都查詢（雖然 SELECT 1 開銷極小），可改用閒置檢測：

• testWhileIdle=true
• timeBetweenEvictionRunsMillis=300000（每 5 分鐘掃描一次閒置連線）
• minEvictableIdleTimeMillis=240000（閒置超過 4 分鐘的連線會被驗證/剔除）

確保 minEvictableIdleTimeMillis < wait_timeout（MySQL 預設 28800 秒），即可在連線被資料庫斷開前主動清理。

為何前幾種方案失效？

1. 修改 wait_timeout：治標不治本，且受限於權限。
2. autoReconnect=true：MySQL 5.0+ 已棄用，且不建議在生產環境使用。
3. maxIdleTime：僅控制連線池內閒置最大時間，無法感知資料庫端已斷開。
4. 定時查詢保活：僅能保活單一連線，無法遍歷池中所有連線，且實作複雜。

正確配置驗證機制，才能從根源上解決「8 小時斷線」難題，保證連線池輸出的永遠是可用連線。