MySQL 句柄數飆升至 10 萬排查實戰：innodb_flush_log_at_trx_commit 關鍵優化

Windows 環境 MySQL 運行十餘小時後，系統響應嚴重延遲，任務管理員顯示 mysqld.exe 句柄數高達 100,000+。經排查發現，即便配置了 skip-innodb，InnoDB 相關後台線程仍在運作，導致資源洩漏。核心突破口在於 innodb_flush_log_at_trx_commit 參數調優。

現象與初步誤區

• 現象：句柄數持續增長，系統整體卡頓，非 MySQL 進程亦受影響
• 誤區：以為 skip-innodb 完全禁用 InnoDB，實際上僅禁用建表預設引擎，InnoDB 核心子系統（日誌、緩衝池、清除線程）仍載入運行
• 嘗試失效：調整 innodb_buffer_pool_size 從 8M 降至 1M 無改善

關鍵參數：innodb_flush_log_at_trx_commit

實戰調優過程與效果

# my.cnf / my.ini 新增
[mysqld]
innodb_flush_log_at_trx_commit = 2

調優前： 句柄數 100,000+，系統嚴重卡頓
調優後： 句柄數穩定在 20,000 左右，其他程式響應恢復正常

深度原理解析

預設值 1 導致每次 COMMIT 觸發 fsync() 系統呼叫，強制資料從 OS 快取刷入物理磁碟。高併發寫入場景下，fsync 成為嚴重瓶頸，導致：

1. 使用者線程大量堵塞在 sync 狀態
2. InnoDB 內部清除線程、合併線程積壓工作項
3. 作業系統層面檔案描述符、句柄持續累積無法釋放

改為 2 後，寫入僅到 OS 頁面快取（write()），由背景 fsync 線程批次刷盤，極大降低同步阻塞，間接解決句柄洩漏連鎖反應。

配置檢查清單

1. 確認 skip-innodb 不等於禁用 InnoDB 子系統，相關參數仍生效
2. 生產環境建議 innodb_flush_log_at_trx_commit = 2 + sync_binlog = 1 組合（Binlog 強一致 + Redo Log 高性能）
3. 核心業務若要求極致安全，保持 1 但必須配合電池備援快取（BBWC/RAID 卡快取）或 NVMe 高 IOPS 設備
4. 監控指標：Innodb_os_log_fsyncs、Innodb_log_waits、句柄數趨勢

從 10 萬句柄到 2 萬穩定，單參數調優釋放系統產能，彰顯 MySQL 參數工程學的精準杠桿效應。