MySQL Thread Cache 深度解析：原理、監控指標與調優實戰

MySQL 每個連線對應一個執行緒，頻繁建立/銷毀執行緒會消耗大量 CPU 與記憶體。thread_cache 正是為了解決此問題而設計的「執行緒池」機制。本文從狀態變數、核心參數、實測關係式、調優建議四個維度深度剖析。

四大核心狀態變數

SHOW GLOBAL STATUS LIKE 'Thread%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 12    |  -- 緩存池中閒置執行緒數
| Threads_connected | 28    |  -- 當前開啟連線數 = SHOW PROCESSLIST 行數
| Threads_created   | 156   |  -- 歷史累計建立執行緒總數
| Threads_running   | 3     |  -- 真正在執行查詢的執行緒數（非睡眠）
+-------------------+-------+

關係公式（穩態下）

Threads_created = (Threads_connected - Threads_cached) + 初始建立數

• 連線斷開 → 若 Threads_cached < thread_cache_size，執行緒放入緩存（Threads_cached++，Threads_connected--）
• 新連線 → 若 Threads_cached > 0，直接從緩存取用（Threads_cached--，Threads_connected++），不增加 Threads_created
• 緩存耗盡 → 必須 pthread_create 新執行緒（Threads_created++）

因此：Threads_created 增長速度 = 未命中緩存的新連線率。

關鍵參數：thread_cache_size

SHOW VARIABLES LIKE 'thread_cache_size';
-- 預設值通常為 0~100（視版本與 max_connections 自動計算）

官方建議：Connections / Threads_created > 0.9 即表示緩存命中率良好。若比率偏低且 Threads_created 快速增長，應調大 thread_cache_size。

實測圖表解讀

• 綠線 Threads_connected：並發連線波動
• 藍線 Threads_cached：與連線數呈負相關，驗證「連線釋放→入緩存」
• 紅線 Threads_created：階梯式上升，平台期代表緩存命中
• Threads_running 始終 ≤ Threads_connected，通常極低

調優實戰清單

1. 觀察基線：持續收集 1 小時 Threads_created、Connections，計算命中率
2. 設定值：thread_cache_size = min(100, max_connections / 10) 為起步值，再按命中率微調
3. 避免過大：緩存佔用記憶體（每執行緒 ~256KB~1MB），極大值可能擠佔 Buffer Pool
4. 配合連線池：應用層已有 HikariCP、Druid 等連線池時，MySQL 端 thread_cache_size 可適當調小（如 32~64），避免雙層池浪費
5. 監控告警：Threads_created / Uptime > 10/秒 觸發告警，排查連線風暴或連線池洩漏

dstat MySQL 臨時表監控插件（附錄）

文末提供 Python 插件原始碼，可定期查詢 performance_schema.statements_with_temp_tables 統計記憶體/磁碟臨時表比例，納入 dstat 監控面板。

總結：thread_cache 是低成本、高收益的調優點。只要 Threads_created 不再暴增，通常不需過度調大；重點應放在應用層連線池複用與避免短連線風暴。