MySQL 連線閒置超時導致斷線問題：wait_timeout 調整與連線池最佳實務

問題現象

應用程式啟動後一段時間（預設 8 小時 = 28800 秒）未使用資料庫連線，再次操作報錯：

Communications link failure
The last packet successfully received from the server was X milliseconds ago...

原因：MySQL 5.x 修改了閒置連線處理機制，超時後伺服器主動斷開，舊版驅動的自動重連（Reconnect）機制失效。

方案一：調整伺服器端超時參數（治標）

編輯 my.cnf / my.ini [mysqld] 區段：

[mysqld]
wait_timeout = 604800          # 7 天（秒）
interactive_timeout = 604800   # 互動式客戶端同步調整

重啟 MySQL 生效。驗證：SHOW VARIABLES LIKE 'wait_timeout';

缺點：長連線佔用資源，若連線洩漏會耗盡 max_connections。

方案二：應用層連線池管理（治本，推薦）

核心原則

• 連線存活時間 < wait_timeout：確保連線在伺服器斷開前被池子淘汰或驗證。
• 借用前驗證：pool_pre_ping / testWhileIdle / validationQuery 執行輕量查詢（如 SELECT 1）。
• 歸還時重置：避免事務、臨時表、會話變數殘留。

方案三：驅動層自動重連（輔助）

• MySQL Connector/J：連線 URL 加 autoReconnect=true（不推薦生產環境依賴此項）。
• MySQL Connector/Python：autocommit=True 搭配重試邏輯。
• Go：database/sql 內建重試需自行實作。

監控與告警

• 監控 Threads_connected、Aborted_connects、Connection_errors_internal。
• 設定連線池洩漏偵測（HikariCP leakDetectionThreshold）。
• 定期檢視 SHOW PROCESSLIST 發現長時間 Sleep 連線。

總結建議

1. 優先完善連線池設定（方案二），從根本解決閒置斷線與資源洩漏。
2. 適度調大 wait_timeout 作為安全網（方案一）。 3. 避免依賴驅動自動重連，改由應用層實作冪等重試邏輯。

1. 上一篇文章： MySQL Root 密碼重置完整教學：Windows 平台逐步操作指南
2. 下一篇文章： MySQL 以 UTF-8 儲存、GBK 輸出的字符集轉換實戰：PHP 連線層動態切換方案

MySQL 資料庫相關知識

MySQL 體系架構深度解析：從連接器到儲存引擎的完整圖譜

架構總覽 MySQL 採用**分層架構**，清晰分離「服務層

MySQL 5.0 圖文安裝教程（Windows 自定義安裝）

MySQL 5.0.27 Windows 安裝包 mysql

MySQL 資料庫核心概念與常用顯示命令全攻略

MySQL 資料庫概述 MySQL 作為全球最流行的開源關係

解決 MySQL 啟動報錯「The server quit without updating PID file」完整排查指南

故障現象 在 Red Hat 6 + MySQL 5.6 環