MySQL 交互式 vs 非交互式連接：wait_timeout 與 interactive_timeout 深度解析與連接池優化實戰

核心概念區分

參數機制深度解析

• 線程啟動時，根據客戶端類型（CLIENT_INTERACTIVE 標誌）決定會話級 wait_timeout 初始值
• 交互式客戶端 → 會話 wait_timeout = 全局 interactive_timeout
• 非交互式客戶端 → 會話 wait_timeout = 全局 wait_timeout
• mysql_real_connect() 內部根據調用參數設定 CLIENT_INTERACTIVE

查看與修改

-- 查看全局值
SHOW VARIABLES LIKE '%timeout%';

-- 修改當前會話（斷開失效）
SET SESSION wait_timeout = 3600;

-- 修改全局（需寫入配置文件並重啟生效）
-- my.cnf [mysqld] 區塊
wait_timeout = 3600
interactive_timeout = 3600

經典「8 小時斷連」問題

現象

應用啟動後閒置超過 8 小時，再次請求拋出：
Communications link failure due to underlying exception

根因

1. 連接池預建連接（如 Tomcat 啟動時向 MySQL 申請 N 條連接）
2. 閒置超過 wait_timeout，MySQL 主動 KILL 掉這些連接
3. 連接池不知情，仍持有失效連接
4. 業務借用失效連接執行 SQL → 異常

解決方案：連接池端驗證機制（以 c3p0 為例）

true   
true  


300  
SELECT 1   -- 輕量級驗證查詢


C3P0TestTable

驗證策略對比

wait_timeout 該設多大？

• 自用生產環境： 默認 8 小時通常足夠，配合 idleConnectionTestPeriod 更穩健
• 共享主機/雲資料庫： 服務商可能設極小值（如 10 秒）強制釋放資源
• 高併發核心業務： 設 30-60 分鐘，配合連接池最大/最小閒置連接數動態調整
• 切勿盲目設極小： 會導致頻繁建連、CPU 飆升、吞吐下降

事務邊界優化：減少驗證頻率

將業務邏輯包裝在 @Transactional 中，一個 HTTP 請求對應一個事務，連接只在事務開始時借用、結束時歸還。
配合 testConnectionOnCheckin 或 idleConnectionTestPeriod，大幅減少驗證開銷。

總結

1. 搞清交互/非交互兩類連接對應的超時參數
2. MySQL 端設合理 wait_timeout（建議 ≥ 30 分鐘）
3. 應用端必須啟用連接池驗證機制（推薦 idleConnectionTestPeriod）
4. 事務邊界清晰，減少連接借用/歸還頻率
5. 監控連接池指標：活躍數、閒置數、等待數、驗證失敗數