MySQL 源碼學習筆記：偷窺線程模型

初讀 MySQL 源碼，感覺代碼風格參差不齊，註釋隨意，各文件風格迥異。這大概是因為 MySQL 經歷了無數大牛之手，融合了眾長；也可能是自己見識淺薄，習慣了自己的編碼風格。懷著敬畏之心，踏上源碼探索之旅。

學習切入點：從客戶端動作反推服務端邏輯

MySQL 作為大型底層軟件，從 main 函數逐行閱讀極易陷入細節泥沼。更現實的路徑是：通過客戶端操作觸發服務端行為，再追蹤對應代碼。規劃以下 SQL 場景作為切入點：

• 登錄：mysql.exe -uroot -p → 觀察通信、鑒權、任務分發
• DDL：CREATE TABLE → 解析邏輯、存儲引擎差異
• DML：INSERT → B+ 樹操作
• 查詢：SELECT → 語法樹構建與優化
• 事務：ROLLBACK → 事務實現機制

線程創建機制探秘

MySQL 支援高併發，必有專門線程處理連接創建。搜尋 _beginthread 和 CreateThread 發現兩套封裝：

• mysys/my_winthread.c → pthread_create 調用 _beginthread
• innobase/os0thread.c → os_thread_create 調用 CreateThread

原來 InnoDB 作為插件式存儲引擎，自帶底層線程封裝。這正是 MySQL 插件架構靈活性的體現——用戶可按需開發專屬存儲引擎。

pthread_create 核心邏輯

map->func = func;
map->param = param;
_beginthread(pthread_start, stack_size, map);

新線程入口固定為 pthread_start，用戶傳入的函數 func 與參數 param 掛載在 map 結構體上。推測 pthread_start 內部會執行 map->func(map->param)。這層封裝的設計意圖值得深思。

啟動階段線程快照

在 pthread_create 斷點處觀察線程列表，發現 InnoDB 已預創建多個後台線程：

隨後創建的三個 _threadstart 線程對應：

• create_shutdown_thread → handle_shutdown（關閉處理）
• start_handle_manager → handle_manager（管理器）
• handle_connections_sockets → handle_connections_sockets（連接監聽）

連接監聽線程作為最後創建，確保所有核心服務就緒後才對外提供服務。下一步將深入分析登錄協議與資源分配機制。