PHP 慢速日誌導致 MySQL 連線中斷問題深度分析

在生產環境中開啟 PHP-FPM 慢速日誌（request_slowlog_timeout）是效能調優的常規手段，但某些情況下卻可能觸發 Lost connection to MySQL server during query (錯誤碼 2013) 的離奇故障。本文記錄一次真實排查過程，揭示慢速日誌與資料庫連線中斷的隱性關聯。

故障現場

• 環境：PHP-FPM + Nginx + MySQL
• 慢速日誌閾值：request_slowlog_timeout = 10s
• 觸發場景：後台批次處理迴圈（>300 次），每次執行相同 SQL
• 現象：Nginx 存取日誌顯示請求耗時約 12 秒，MySQL 拋出 2013 錯誤
• 嘗試無效：mysql_ping() 重連檢查無法解決

關鍵轉折點

抱著「死馬當活馬醫」心態關閉 PHP 慢速日誌後，問題瞬間消失。這表明慢速日誌機制本身干擾了長時間執行的資料庫操作。

根因深度剖析

1. PHP-FPM 慢速日誌工作原理

當請求執行超過閾值，PHP-FPM 主進程會發送 SIGALRM 信號給工作進程，強制中斷當前執行並導出堆疊追蹤。此過程具有非同步中斷特性：

• 工作進程可能正在執行 mysql_query() 等阻塞式系統呼叫
• 信號處理器執行期間，原有的 MySQL 連線狀態可能被破壞
• MySQL 客戶端庫（mysqlnd/libmysql）未預期到執行流被外部中斷

2. 為什麼 mysql_ping() 失效

// 典型的重連檢查邏輯
if (!mysql_ping($link)) {
    $link = mysqli_connect(...); // 重新連線
}
mysqli_query($link, $sql);

mysql_ping() 僅檢查連線是否存活，但無法預測「下一條 SQL 執行期間」是否會再次被慢速日誌中斷。迴圈中每次查詢約 12 秒，遠超 10 秒閾值，導致每次查詢都會被中斷一次，連線狀態處於持續不穩定狀態。

3. 信號處理與 MySQL 協定的衝突

MySQL 協定要求命令/回應嚴格配對。慢速日誌中斷導致：

1. PHP 發送查詢命令
2. 等待回應期間觸發 SIGALRM
3. 信號處理器執行堆疊導出（可能耗費數百毫秒）
4. MySQL 伺服器端超時關閉連線（預設 wait_timeout 或 net_read_timeout）
5. PHP 恢復執行時讀取到斷開的連線 → 2013 錯誤

解決方案與最佳實踐

方案一：調整慢速日誌閾值（推薦）

將閾值設為業務允許的最大執行時間 2 倍以上：

; php-fpm.conf
request_slowlog_timeout = 30s  ; 批次任務建議 30-60 秒
request_slowlog_trace_depth = 20

方案二：批次任務獨立進程/排程執行

• 使用 CLI 模式執行長時間批次腳本（php script.php），完全繞過 PHP-FPM 慢速日誌
• 搭配 pcntl_signal 自行處理超時邏輯

方案三：優化 SQL 與迴圈邏輯

• 將迴圈內重複 SQL 改為批次操作（INSERT ... VALUES (...), (...) 或預處理語句）
• 單次查詢控制在 1-2 秒內，避免觸發慢速日誌

方案四：MySQL 連線參數優化

$mysqli = new mysqli(...);
$mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$mysqli->options(MYSQLI_OPT_READ_TIMEOUT, 30);  // PHP 7.2+ 支援
$mysqli->options(MYSQLI_OPT_WRITE_TIMEOUT, 30);

避坑指南

結論：PHP 慢速日誌是雙面刃，長時間資料庫操作場景下需謹慎配置閾值，或將此類任務遷移至 CLI 環境執行，從根源避免信號中斷干擾 MySQL 協定交互。