SKIP LOCKED 是为多行任务表并发抢行设计的机制，非加速吞吐；其生效需满足联合索引、显式事务、精确UPDATE、合适隔离级别等严苛条件，单行热点场景无效。
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 是新事务，此时别人已经抢先锁走了刚查到的那行。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须显式开启事务：
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 被硬性禁用。
- 确认当前会话隔离级别：
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。
