秒殺業務 MySQL 優化實戰（一）：高並發單行更新瓶頸分析與 innodb_thread_concurrency 限流實測

秒殺業務 MySQL 優化實戰（一）

雙十一、小米饑餓營銷將「秒殺」推向高峰。本文從數據庫視角剖析秒殺核心壓力點——高並發更新同一行記錄的鎖爭用，並實測 innodb_thread_concurrency 限流效果。

秒殺業務建模

典型事務流程：

BEGIN;
INSERT INTO stock_log ...;          -- 記錄日志
SELECT count FROM stock WHERE id=1 AND count>0 FOR UPDATE;  -- 加鎖讀
UPDATE stock SET count=count-1 WHERE id=1 AND count>0;      -- 扣減庫存
COMMIT;

所有請求聚焦 stock.id=1 這一行，InnoDB 行鎖導致 物理串行執行，並發度越高，鎖等待/死鎖檢測開銷指數級上升。

壓測數據：並發度 vs TPS

隨並發從 32 升至 256，TPS 從峰值 12k 急跌至 4k，CPU 絕大部分消耗在 lock_deadlock_recursive（死鎖檢測）與 lock_rec_get_prev（鎖鏈遍歷）。

perf 火焰圖證據

59.06%  mysqld  [.] lock_deadlock_recursive
16.63%  mysqld  libc-2.13.so  [.] 0x115171
3.09%   mysqld  [.] lock_rec_get_prev
2.96%   mysqld  [.] my_strnncollsp_utf8

鎖子系統佔據近 80% CPU，確認瓶頸為「鎖等待 → 死鎖檢測 → 喚醒」循環。

嘗試方案：innodb_thread_concurrency 限流

該參數控制進入 InnoDB 內核的併發線程數（0 表示不限制）。實測設為 16：

• 128 併發：TPS 4300 → 7200（提升 65%）
• 256 併發：TPS 仍不足 5000，效果邊際遞減

深度原因分析

innodb_thread_concurrency 僅限制存儲引擎層入口，MySQL Server 層（SQL 解析、優化器、執行器）的線程仍在積極搶鎖、等待、喚醒，上下文切換開銷未根本降低。本質是「應用層排隊」轉移為「Server 層排隊」。

下一步優化方向（預告）

• 應用層排隊：Redis Lua / Memcached CAS 預扣庫存，僅成功請求落庫
• 業務分片：庫存表按倉庫/區域拆分，將單行熱點分散為多行
• 彙總異步扣減：記錄請求日志，後台單線程批量扣減，回寫結果
• 硬件層：NVMe SSD 降低 redo log fsync 延遲，啟用 innodb_flush_log_at_trx_commit=2（允許秒級丟失）

單行熱點更新是分佈式系統經典難題，單純數據庫參數調優難以根治，需「應用排隊 + 業務分片 + 異步化」組合拳破局。