SKIP LOCKED 本身不构成分布式队列，需配合事务边界、索引设计和原子更新才能实现真正不冲突的消费；若WHERE未走索引、ORDER BY无索引、事务未显式开启或隔离级别不当，仍会卡住。
SKIP LOCKED 本身不构成分布式队列，它只是让多个消费者能并发“抢到不同行”，真正可用的队列必须靠事务边界、索引设计和原子更新共同兜底。
为什么直接写 SELECT ... FOR UPDATE SKIP LOCKED 还是会卡住
这不是语法写错了，而是查询没落到可跳过的行集合上：
-
WHERE条件没走索引 → MySQL 全表扫描，锁住大量无关行，SKIP LOCKED只能跳“已被锁的行”，跳不掉“本不该扫到的行” -
ORDER BY字段无索引或值高度重复（比如全是'PENDING'）→ 优化器每次选中物理位置不同的行，多个事务看似跳过彼此，实则捞出同一条业务上已失效的记录 - 事务未显式开启（
AUTOCOMMIT=1）→SELECT ... FOR UPDATE SKIP LOCKED执行完立刻释放锁，后续UPDATE是新事务，别人早已插队 - 隔离级别为
READ UNCOMMITTED或SERIALIZABLE→ 前者不支持SKIP LOCKED，后者直接报错ER_NOT_SUPPORTED_YET
怎么写出真正不冲突的队列消费 SQL
必须把“查、锁、判、更”压进一个事务，并确保索引覆盖全部过滤和排序路径：
- 建联合索引时字段顺序不能错：例如
CREATE INDEX idx_status_id ON jobs (status, id)，status在前才能高效过滤WHERE status = 'PENDING'，id在后才支撑ORDER BY id - 事务第一句必须是带
SKIP LOCKED的SELECT，且只查主键和必要字段，避免锁升级 - 拿到结果后立刻检查
id是否为空；若为空，说明无可用任务，直接COMMIT退出，不要重试或sleep -
UPDATE必须用主键精确匹配，并复核业务状态：UPDATE jobs SET status = 'PROCESSING' WHERE id = ? AND status = 'PENDING'—— 防 ABA 场景下误更新已变更状态的记录
SKIP LOCKED 在哪些场景下完全无效
它不是万能锁逃逸方案，以下情况它帮不上忙：
- 热点单行更新：比如所有任务都指向同一张优惠券的总库存（
coupon_id = 1），SKIP LOCKED没意义——没别的行可跳，大家还是卡在这一行上等待 - 子查询中使用：
UPDATE orders SET status = 'paid' WHERE id IN (SELECT id FROM items FOR UPDATE SKIP LOCKED)会直接报错ER_NOT_SUPPORTED_YET -
WHERE中混用函数或类型隐式转换（如WHERE DATE(created_at) = '2026-06-06'）→ 导致索引失效，退化为全表扫描 - 应用层在
SELECT和UPDATE之间插入远程调用、复杂计算等耗时逻辑 → 锁持有时间拉长，别人更难抢到，也增加空跑概率
真正容易被忽略的是事务边界控制
SKIP LOCKED 的有效性极度依赖事务是否真正包住整条链路。一旦 SELECT 和 UPDATE 被业务逻辑隔开，或者 UPDATE 条件漏掉关键校验，它就退化成一个看起来高级、实则无效的语法糖。比如 Spring 的 @Transactional 默认把整个方法包进一个事务，但若中间调了积分服务，锁就白白持有了几百毫秒 —— 这时候不是并发不够，而是锁拖累了并发。
