MySQL 線程池核心原理深度解析（一）：架構設計與關鍵機制

前言：為什麼需要線程池

高並發是服務端應用永恆的主題。MySQL 5.6 前採用 One-Connection-Per-Thread 模式：每個連接獨佔一線程，請求結束銷毀線程。雖有 thread_cache 緩解創建銷毀開銷，但無法解決連接數暴增帶來的問題：

• 線程數 = 連接數，內存消耗線性增長（每線程默認 256KB 棧）。
• 大量線程導致上下文切換頻繁，CPU Cache 命中率驟降。
• 鎖、I/O 等資源競爭劇增，服務出現抖動甚至不可用。

Thread Pool 將處理單位從「連接」細化為「語句」，一個 Worker 線程可服務多個連接的請求。配合合理的 thread_pool_size（通常設為 CPU 核心數），在硬件資源可控範圍內實現高吞吐、低延遲、穩定的服務能力。

三種調度方式與統一接口

MySQL 通過 thread_handling 參數支持三種模式：

• No-Threads：主線程直接處理，僅用於調試。
• One-Thread-Per-Connection：傳統模式。
• Pool-Threads：線程池模式（本文重點）。

核心是 scheduler_functions 結構體，包含一組函數指針，不同模式填入不同回調實現：

struct scheduler_functions {
    uint max_threads;
    uint *connection_count;
    ulong *max_connections;
    bool (*init)(void);
    bool (*init_new_connection_thread)(void);
    void (*add_connection)(THD *thd);
    void (*thd_wait_begin)(THD *thd, int wait_type);
    void (*thd_wait_end)(THD *thd);
    void (*post_kill_notification)(THD *thd);
    bool (*end_thread)(THD *thd, bool cache_thread);
    void (*end)(void);
};

線程池模式的實現 tp_scheduler_functions：

static scheduler_functions tp_scheduler_functions = {
    0,                       // max_threads (動態)
    NULL, NULL,
    tp_init,                 // init: 初始化線程池
    NULL,                    // init_new_connection_thread: 線程池無需
    tp_add_connection,       // add_connection: 分發連接到 Group
    tp_wait_begin,           // thd_wait_begin: 進入等待狀態統計
    tp_wait_end,             // thd_wait_end: 結束等待狀態統計
    tp_post_kill_notification, // post_kill_notification: Kill 通知
    NULL,                    // end_thread: 線程池無線程緩存概念
    tp_end                   // end: 銷毀線程池
};

連接管理流程

1. 主監聽線程 poll 監聽端口，accept 新連接。
2. 創建通信 Socket、初始化 THD、VIO 對象。
3. 根據 thread_handling 設置 THD 的 scheduler 函數指針。
4. 調用 scheduler->add_connection(thd) 進入具體調度邏輯（線程池即 tp_add_connection）。

線程池核心參數

線程池架構圖解

每個綠色方框為一個 Group，包含：

• 一個優先隊列 + 一個普通隊列
• 一個 Listener 線程（可動態轉換為 Worker）
• 多個 Worker 線程（數量動態調整，受 oversubscribe 限制）

全局一個 Timer 線程巡檢所有 Group，防止停滯、處理超時連接。

九大關鍵接口詳解

1. tp_add_connection — 處理新連接

1. 創建 Connection 對象封裝 THD。
2. 根據 thread_id % group_count 確定目標 Group。
3. 將 Connection 推入該 Group 的普通隊列。
4. 若 Group 當前活躍線程數為 0，創建一個 Worker 線程。

2. worker_main — Worker 主循環

1. 調用 get_event 獲取請求。
2. 有請求 → handle_event 處理。
3. 無請求 → 退出線程（若為 Listener 則轉入監聽邏輯）。

3. get_event — 獲取請求（含線程角色轉換）

1. 嘗試從隊列取請求，成功即返回。
2. 若 Group 無 Listener，當前線程轉為 Listener，調用 epoll_wait 阻塞監聽。
3. 若有 Listener，將自己加入等待隊列頭部，pthread_cond_timedwait 休眠 thread_pool_idle_timeout。
4. 超時未被喚醒 → 線程退出；被喚醒 → 跳轉步驟 1。
5. 註：取請求前檢查活躍線程數是否超過 oversubscribe + 1，超過則強制休眠。

4. handle_event — 處理請求

1. 未登錄連接 → 進行認證。
2. 綁定 THD 實例信息。
3. 讀取網絡包，解析命令。
4. 循環調用 do_command 執行。
5. 獲取 Socket FD，若未註冊 Epoll → epoll_ctl ADD；已註冊 → epoll_ctl MOD 重置事件。

5. listener — 監聽線程

1. 調用 epoll_wait 監聽 Group 內所有連接 FD。
2. 事件就緒 → 從 epoll_event 取出 Connection。
3. 根據優先級（如已開啟事務、持有鎖）放入優先隊列或普通隊列。
4. 若隊列為空 → Listener 轉為 Worker 繼續處理。
5. 若 Group 無活躍 Worker → 喚醒/創建一個 Worker。

6. timer_thread — 監控線程

1. 無 Listener 且近期無 I/O 事件 → 創建/喚醒 Worker。
2. Group 長時間未處理請求但隊列非空 → 判定 Stall，喚醒/創建 Worker。
3. 檢查連接是否超時（wait_timeout/interactive_timeout）。

7. tp_wait_begin / tp_wait_end — 等待狀態統計

用於維護 active_thread_count 與 waiting_thread_count，供 Timer 線程決策。注意：waiting_threads 隊列存的是「空閒可執行線程」，非「等待鎖/I/O 的阻塞線程」。

8. tp_init / tp_end — 生命週期

分別調用 thread_group_init 初始化所有 Group（含 Epoll 創建）與 thread_group_close 銷毀。

連接池 vs 線程池：協同而非替代

• 連接池：Client 端，復用物理連接，減少握手開銷，控制單應用連接數，但無法控制整個集群對 DB 的總連接數。
• 線程池：Server 端，一線程服務多連接的語句請求，將服務線程數控制在 CPU 核心級，解決高連接數導致的並發抖動。
• 最佳實踐：Client 使用連接池 + Server 開啟線程池，雙重保障。

兩大優化機制

1. 調度死鎖解決 — 優先隊列

場景：事務 A 持有鎖但在繁忙 Group 排隊；事務 B 依賴 A 釋放卻在閒置 Group 被調度卻因鎖阻塞。
解決：Group 內引入優先隊列，將「已持有鎖」或「已開啟事務」的連接請求置入優先隊列，Worker 優先消費，加速鎖釋放。

2. 大查詢/ Dump 任務隔離 — 不計入 Oversubscribe

問題：大查詢（如 Dump）佔滿 Worker 導致正常業務請求無法調度（Group Stall）。Timer 雖會創建新 Worker，但若全是大查詢會拖垮整機。
解決：識別 Dump 類任務（如 SELECT * INTO OUTFILE、特定用戶/線程標記），其 Worker 不計入 thread_pool_oversubscribe 限制，確保業務 Worker 名額不被佔用。