為什麼消息隊列不用 MySQL？高併發下「查詢-修改」競態條件導致不可靠

新手常問：消息隊列不就是「存進去、取出來」嗎？為什麼不直接用 MySQL 建張表，state=0 未讀、state=1 已讀，甚至讀完刪除？本文從併發、效能、可靠性三個維度，揭示 MySQL 做隊列的致命缺陷。

MySQL 做隊列的典型邏輯

-- 生產者
INSERT INTO mq_table (payload, state) VALUES ('msg', 0);

-- 消費者（輪詢）
SELECT * FROM mq_table WHERE state = 0 LIMIT 1 FOR UPDATE;
UPDATE mq_table SET state = 1 WHERE id = ?;
-- 或刪除
DELETE FROM mq_table WHERE id = ?;

三大致命缺陷

1. 高併發下的「查詢-修改」競態條件

• 多消費者並發 SELECT ... FOR UPDATE，資料庫行鎖爭用極其嚴重。
• 即使加鎖，SELECT 到 UPDATE 間隙，其他事務可能已修改，導致重複消費或消費丟失。
• MySQL 鎖升級（行鎖→表鎖）頻繁，吞吐量上不去。

2. 輪詢模式極其低效

• 消費者需定時 SELECT ... WHERE state=0，空輪詢浪費 CPU/IO。
• 長輪詢需維持長連接，MySQL 連接數限制（默認 151）極易耗盡。
• 無法實現真正的「推送」語義，延遲不可控。

3. 缺乏隊列核心特性

何時可以用 MySQL 做隊列？

• 極低併發（< 10 QPS）、無順序要求、無重試需求、團隊無運維 MQ 能力的內部小工具。
• 作為「最後手段」的備用存儲（如 MQ 持久化備份表）。

輕量級替代方案

• Redis List/Stream： LPUSH/BRPOP、XADD/XREADGROUP，單機 10 萬+ QPS，支援消費組、ACK、阻塞讀。
• SQLite + 應用層隊列： 單文件、零配置、適合嵌入式/邊緣設備。
• Disruptor / RingBuffer： 進程內無鎖隊列，納秒級延遲，適合高頻交易系統。

結論：MySQL 是關係型數據庫，不是消息中間件。用對工具，少寫 Bug，睡好覺。