MySQL 線程池原理深度解析：從調度模型到源碼級實現

前言：為什麼需要線程池？

MySQL 5.6 引入線程池，解決 One-Thread-Per-Connection 模式下的高併發痛點：線程頻繁創建/銷毀、高內存佔用、上下文切換風暴、鎖競爭加劇。線程池通過預創建固定數量線程、一線程服務多連接（最小調度單位為 Statement），在充分利用硬體資源前提下，平滑吸收連接洪峰，避免服務抖動。

一、 三種連接管理模式與統一調度接口

MySQL 通過 thread_handling 參數切換：

• NO_THREADS：主線程直連（調試用）
• ONE_THREAD_PER_CONNECTION：傳統模式
• POOL_OF_THREADS：線程池模式

核心是 scheduler_functions 函數指針結構體，不同模式註冊不同回調實現：

struct scheduler_functions {
  uint max_threads;
  bool (*init)(void);
  void (*add_connection)(THD *thd);
  void (*thd_wait_begin)(THD *thd, int wait_type);
  void (*thd_wait_end)(THD *thd);
  bool (*end_thread)(THD *thd, bool cache_thread);
  void (*end)(void);
  // ... 其他回調
};

線程池模式註冊 tp_scheduler_functions，關鍵回調包括 tp_add_connection、tp_wait_begin/end、tp_init/end。

二、 線程池架構圖解

• Group：由 thread_pool_size 決定數量（通常=CPU 核心數），每 Group 一個 Listener 線程 + 多個 Worker 線程。
• 隊列：優先隊列（持有鎖/活躍事務）+ 普通隊列。
• Timer 線程：全局單例，巡檢 Group 是否「停滯」（Stall），檢查連接超時。

三、 核心參數詳解

四、 關鍵接口流程深度剖析

1. tp_add_connection：新連接分發

1. 創建 connection 對象
2. thread_id % group_count 決定歸屬 Group
3. 放入對應 Group 隊列
4. 若 Group 活躍線程數為 0，創建 Worker

2. worker_main：Worker 主循環

1. get_event() 獲取請求
2. 有請求 → handle_event() 處理
3. 無請求 → 轉 Listener 或進入定時等待（thread_pool_idle_timeout），超時退出

3. get_event：智能獲取任務

• 優先檢查活躍線程數是否超過 oversubscribe+1，超過則休眠
• 若無 Listener，當前線程升級為 Listener（epoll_wait 閒聽）
• 否則加入等待隊列頭部，定時休眠

4. handle_event：請求處理全流程

1. 未認證 → 登錄驗證
2. 綁定 THD 實例
3. 讀取網絡包、解析命令
4. do_command() 循環處理
5. 將 Socket 註冊到 Group 的 epoll 監聽集合

5. listener：基於 epoll 的高效監聽

1. epoll_wait() 阻塞監聽 Group 內所有連接 Socket
2. 事件就緒 → 根據優先級放入優先/普通隊列
3. 若隊列為空 → Listener 降級為 Worker
4. 若無活躍 Worker → 喚醒一個

6. timer_thread：防停滯守護者

• 無 Listener 且無近期 I/O 事件 → 創建/喚醒 Worker
• Group 長時間未處理請求但隊列有任務 → 判定 Stall，強制喚醒/創建 Worker
• 檢查連接超時

五、 線程池 vs 連接池：端邊協同

• 連接池：Client 端，復用連接，減少建連開銷，控制單應用連接數，但無法控制整個集群總連接數。
• 線程池：Server 端，一線程服務多連接（Statement 級），控制服務線程總數，降低上下文切換與資源競爭，應對高連接數洪峰。
• 協同效果：Web Server 維護小連接池，DB 線程池以少量 Worker 服務大量連接請求。

六、 線程池優化實戰：死鎖與大查詢

1. 調度死鎖與優先隊列

場景：事務 A 持有鎖但所在 Group 忙碌無法調度；事務 B 等待 A 的鎖卻能被調度 → 形成「調度死鎖」。
解決：引入優先隊列，持有鎖/活躍事務的請求優先入隊，Worker 先處理優先隊列，加速鎖釋放。

2. 大查詢與 Stall 處理

• 業務大查詢：導致所有 Group 達到 oversubscribe 上限，Timer 創建新 Worker 緩解，但根治需 SQL 限流/過濾。
• Dump 任務：長耗時但低併發，不計入 oversubscribe 計數，避免擠佔業務 Worker 槽位。

七、 對比：One-Thread-Per-Connection 核心流程

• create_thread_to_handle_connection：從 Thread Cache 取線程或新建，入口 do_handle_one_connection
• do_handle_one_connection：循環 do_command() 讀取網絡包執行，直到 COM_QUIT
• one_thread_per_connection_end：判斷是否歸還 Thread Cache，否則退出線程

關鍵差異：傳統模式 Worker 自己 poll() 等待網絡包；線程池模式 Worker 專心處理，Listener 統一 epoll_wait 分發，**CPU 利用率更高**。

八、 epoll 在線程池中的生命週期

初始化：tp_init → thread_group_init → io_poll_create → epoll_create
關聯 Socket：handle_event → start_io → io_poll_associate_fd → epoll_ctl(ADD/MOD)
監聽循環：listener → io_poll_wait → epoll_wait
銷毀：tp_end → thread_group_close → close(pollfd)

註：epoll_ctl MOD 用於重新註冊已就緒的舊連接，因 epoll 觸發後會清空事件類型。

九、 函數調用鏈速查表

十、 總結

MySQL 線程池通過 Group 化架構 + epoll 事件驅動 + 優先隊列 + Timer 守護，將「一連接一線程」重構為「N 連接 M 線程（M ≈ CPU 核心數）」，從根本上解決了高併發下的資源爭用與上下文切換瓶頸。理解其調度邏輯、關鍵參數、epoll 整合、死鎖優化，是 DBA 進行極致效能調優的必修課。