MySQL 大量線程卡在 Sending Data 狀態的排查實錄

現象描述

主服務器日均 250 萬動態 PV，查詢約 600 QPS。多次發生「卡死」：服務器未崩潰、資料庫可正常登入，但所有查詢卡在 Sending data 狀態長時間無法完成，簡單 SQL 有時集中在 A 表、有時在 B 表，部分顯示 Locked 或 Update 狀態。

官方說明 Sending data 代表兩種情況：已查詢完畢正發送給客戶端，或正從資料檔讀取資料。官方稱非 Bug 但未給解決方向，推測為配置問題。

排查歷程

1. SQL 優化：卡死 SQL 皆為簡單查詢、消耗低、索引良好，慢查詢日誌無記錄，排除 SQL 問題。
2. OPTIMIZE TABLE：整理表碎片，數日後問題復發。
3. 增加記憶體配置：調大 key_buffer、thread_cache 等，無效。
4. 調整 Query Cache：將 query_cache_size 降至預設 16MB，並將低變動資料靜態化。驚人地 12 天無故障。

後續分析

Query Cache 命中率 75%，但資料更新頻繁導致 Cache 頻繁失效/更新，可能引發鎖競爭。靜態化的產品說明文字雖短（三五十字），但頁面含 7-8 個產品、查詢極頻繁，資料量可觀。不過卡死 SQL 不全來自此表，根因仍在程式端未查出。

另一案例：進程數暴增導致服務掛掉

布衣生活網（4000 IP/日），曾發生 CPU 100%、進程數超過限制（1000→3000 仍不夠），全部卡在 Sending data。排查無死鎖、無未提交事務、修復 InnoDB 表失效，改為 MyISAM 後修復成功並重啟恢復正常。

核心心得

MySQL 進程滿而死的重要原因往往非單純資料庫層面，需結合程式架構、查詢模式、快取策略、表引擎選擇綜合排查。連續解決疑難雜症後，對系統級問題的思考與解決能力顯著提升。