在MySQL 8.0中如何使用SKIP LOCKED实现高并发DML排队消费-mysql教程-PHP中文网

SKIP LOCKED 是为多行任务表并发抢行设计的机制，非加速吞吐；其生效需满足联合索引、显式事务、精确UPDATE、合适隔离级别等严苛条件，单行热点场景无效。

在mysql 8.0中如何使用skip locked实现高并发dml排队消费

SKIP LOCKED 不是用来“加速吞吐”的，它是让多个消费者不互相阻塞地从同一张任务表里抢行的开关——前提是你的 SQL 写法、索引结构、事务边界都严丝合缝。写错任意一环，它就退化成普通 FOR UPDATE，甚至更糟。

WHERE 条件没走索引 → 全表扫描 + 大量无效加锁

这是最常见也是最隐蔽的失效点。比如：

SELECT * FROM jobs WHERE status = 'PENDING' ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED;

如果 status 没单独建索引，或没和 id 组成联合索引，MySQL 就可能执行全表扫描。这时 SKIP LOCKED 只能跳过已被锁的几行，但扫描过程中会尝试对几百上千行加锁（即使最终没选中），后续事务仍大概率撞上同一物理页里的未锁行。

必须建联合索引：CREATE INDEX idx_status_id ON jobs (status, id) —— status 在前才能高效过滤，id 在后才支撑 ORDER BY id 稳定取值
避免在 WHERE 中用函数或隐式转换，例如 WHERE DATE(created_at) = '2026-10-14' 或 WHERE status = 0（字段是字符串）
用 EXPLAIN 验证是否走了索引，type 应为 range 或 ref，且 key 显示用了你建的索引

事务没包住 SELECT + UPDATE → 锁秒放，别人立刻插队

很多人把 SELECT ... FOR UPDATE SKIP LOCKED 当成“取到就锁定”，其实它只在当前事务生命周期内有效。如果 AUTOCOMMIT = 1（默认），那这句执行完事务就提交，锁立刻释放；紧接着的 UPDATE 是新事务，此时别人已经抢先锁走了刚查到的那行。

必须显式开启事务：BEGIN 或 START TRANSACTION 是第一句
SELECT 必须带 SKIP LOCKED，且只查 id 和必要字段（避免锁升级成间隙锁）
拿到结果后立刻检查 id 是否为空；若为空，直接 COMMIT 退出，不要 SLEEP 后重试
UPDATE 必须用主键精确匹配 + 业务状态校验：UPDATE jobs SET status = 'PROCESSING' WHERE id = ? AND status = 'PENDING' —— 这个后置条件防 ABA 问题，哪怕 SELECT 时是 PENDING，UPDATE 前也可能被别人改掉

隔离级别为 SERIALIZABLE → 直接报错禁用 SKIP LOCKED

MySQL 在 SERIALIZABLE 隔离级别下会拒绝 SKIP LOCKED，抛出错误：ERROR 3572 (HY000): Do not wait for lock. 注意：这不是 NOWAIT 报的错，而是 SKIP LOCKED 被硬性禁用。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

确认当前会话隔离级别：SELECT @@transaction_isolation;
生产环境推荐用 REPEATABLE READ（MySQL 8.0 默认）或 READ COMMITTED；前者支持间隙锁防幻读，后者并发更高但需业务层兜底
不要在 Spring 的 @Transactional(isolation = Isolation.SERIALIZABLE) 里用 SKIP LOCKED，否则启动就失败

单行热点竞争 → SKIP LOCKED 根本无用

SKIP LOCKED 只在“多行可选”场景下生效。如果你的业务本质是抢唯一资源，比如扣减某 SKU 的总库存：

SELECT * FROM stock WHERE sku_id = 123 AND count > 0 FOR UPDATE SKIP LOCKED;

那所有消费者都在查同一行，SKIP LOCKED 没别的行可跳，大家还是排队等锁。这时候它和普通 FOR UPDATE 行为一致。

真正适合 SKIP LOCKED 的是任务队列表（jobs）、消息队列表（messages）、分片处理表（shards）这类天然多行、状态可批量流转的场景
单行热点必须换思路：用乐观锁（UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?）、Redis 原子计数器、或预分片（把一个逻辑库存拆成 100 个物理库存行）
别指望靠加索引或调参数让 SKIP LOCKED 在单行场景“变灵光”——它的设计目标就不是解决这个问题

最容易被忽略的是：SKIP LOCKED 的效果完全依赖于 MySQL 查询优化器是否真的按你预期的方式执行计划。哪怕语法全对、索引也建了，一旦优化器因统计信息过期、直方图缺失或小数据量选择全表扫描，整套机制就崩了。所以每次上线前，务必在生产镜像环境用真实数据量跑 EXPLAIN FORMAT=JSON 看 used_range_access_method 和 rows_examined_per_scan。