MySQL NOWAIT 锁定读取失败后如何设计快速降级

在 InnoDB 高并发事务里，SELECT ... FOR UPDATE NOWAIT 的价值不是“让数据库自动重试”，而是把等待变成一个可判断的结果：目标行被占用时立即返回 ERROR 3572 (HY000)。快速降级的关键是先结束当前事务工作单元，再按业务语义选择跳过、读快照或稍后重试。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/innodb-locking-reads.html

先把 NOWAIT 失败变成清晰的事务分支

普通的 FOR UPDATE 会等待持锁事务结束；NOWAIT 则立即失败，不会因为锁冲突在连接池里排队。因此应用层应该只把错误码 3572 视为“当前资源忙”，其他语法、权限或连接错误仍按故障处理，不能统统降级。

-- 当前事务只负责尝试占用一条待处理记录
START TRANSACTION;

-- 过滤条件应命中待处理索引，NOWAIT 不等待已占用的行
SELECT id, payload
FROM job_queue
WHERE id = 42 AND state = 'ready'
FOR UPDATE NOWAIT;

-- 成功拿到锁后才修改状态，并在同一事务中提交
UPDATE job_queue SET state = 'running' WHERE id = 42;
COMMIT;

捕获到 ERROR 3572 时，不要在同一个工作单元里无间隔重复发起同样的锁定读。先回滚或释放应用事务对象，再把这次请求路由到降级分支。这样做的重点不是假设 MySQL 一定会自动回滚，而是明确清理本次未完成的事务意图。

缩小锁定范围，避免把索引问题伪装成降级问题

如果 WHERE 条件没有合适索引，锁定读可能扫描并接触更宽的记录范围。此时大量请求都收到 NOWAIT 失败，真正的瓶颈并不是降级策略，而是一次尝试覆盖了太多候选行。队列表至少要让“状态 + 调度条件 + 唯一标识”形成稳定的访问路径，并让每次领取只对应一个明确任务。

上线前重点检查三件事：过滤字段是否与索引顺序匹配；降级查询是否又回到了同一把冲突锁；成功分支是否只在拿到锁后更新状态。不要为了让失败率下降而移除锁，锁定读取保护的是“读取后还要修改”的一致性窗口。

按业务语义选择三种快速降级

降级不是固定的“改成普通 SELECT”。它取决于这次读取的结果是否可以缺席，以及后续动作是否必须与刚读到的行保持一致。

SKIP LOCKED 会把被锁行从结果集中排除，MySQL 官方明确提示它会产生不一致视图，所以不要用于需要完整事务视图的普通业务查询。对必须写入的请求，返回可识别的 409 或业务级“稍后重试”结果，通常比继续占用连接等待更稳定。

-- 队列消费者可以跳过已被其他消费者占用的任务
START TRANSACTION;
SELECT id, payload
FROM job_queue
WHERE state = 'ready'
ORDER BY id
LIMIT 1
FOR UPDATE SKIP LOCKED;

-- 只有成功选到任务时才更新状态；空结果应提交并结束本轮
UPDATE job_queue SET state = 'running' WHERE id = 43;
COMMIT;

上线时用结果指标约束降级边界

至少记录锁冲突次数、按场景划分的降级次数、空结果比例、最终成功处理数和事务回滚数。冲突率升高但队列吞吐稳定，可能是正常削峰；冲突率和空结果同时升高，往往说明候选范围或索引设计需要复查；所有分支都在重试，则说明应用没有真正消费 ERROR 3572。

发布检查清单可以保持很短：确认只识别锁冲突错误；确认降级前释放事务；确认 SKIP LOCKED 只用于队列语义；确认强一致写入不会退回普通读取；确认重试有次数、退避和最终失败出口。

常见问题

NOWAIT 失败后直接改成普通 SELECT 可以吗？

只适合展示或查询类请求。若后面还要依据这次读取更新同一行，普通读取不能证明已经获得写锁。

SKIP LOCKED 能替代所有 NOWAIT 降级吗？

不能。它会跳过锁定行并返回不完整集合，适合队列消费者，不适合需要完整一致视图的事务。

为什么不在数据库里自动重试？

数据库不知道请求是否允许换任务、读旧值或返回资源忙。把策略放在应用层，才能按业务语义决定是否重试以及何时停止。