SELECT FOR UPDATE NOWAIT 立即报错退出而非等待，只要目标行被其他事务加锁就触发 ERROR 3572，彻底取消等待；它仅支持 SELECT 语句且必须显式开启事务、搭配 FOR UPDATE/SHARE 使用，不适用于 UPDATE/DELETE 或子查询。
SELECT FOR UPDATE NOWAIT 立即失败，不是超时
MySQL 8.0 的 NOWAIT 不是把锁等待时间调短，而是彻底取消等待——只要目标行已被其他事务加锁（FOR UPDATE 或 FOR SHARE），当前语句立刻报错退出，返回固定错误码 ERROR 3572 (HY000)。它不触发 innodb_lock_wait_timeout，该参数在 NOWAIT 场景下完全失效。
常见误用包括：
-
UPDATE ... WHERE id = 123 NOWAIT——NOWAIT不能用于UPDATE/DELETE，只支持SELECT ... FOR UPDATE或SELECT ... FOR SHARE -
SELECT * FROM t WHERE id = 123 NOWAIT—— 缺少FOR UPDATE或FOR SHARE，语法合法但无锁行为，NOWAIT被静默忽略 - 在子查询中写
FOR UPDATE NOWAIT（如WHERE id IN (SELECT ... FOR UPDATE NOWAIT)）—— 外层不加锁，子查询的NOWAIT不传导，也不影响外层执行
SKIP LOCKED 跳过被锁行，结果集变小
SKIP LOCKED 让 SELECT ... FOR UPDATE 自动跳过已被加锁的行，这些行不会出现在结果集中。它不报错、不等待，适合任务分发、队列消费等场景。
但要注意行为边界：
- MySQL 8.0.22 之前，
WHERE sku_id IN (123, 456) FOR UPDATE SKIP LOCKED不保证只跳单个被锁 ID；优化器可能全扫索引范围，导致部分本应命中的行也被跳过 -
SKIP LOCKED只跳行级锁（record lock），对间隙锁（gap lock）无效；若因 gap lock 阻止插入，它不生效 - 必须显式开启事务（
START TRANSACTION或SET autocommit = 0），否则退化为普通读，SKIP LOCKED无意义
应用层必须捕获 ERROR 3572，不能泛化处理
NOWAIT 报错不是异常，而是设计意图：快速失败。错误码固定为 3572，和死锁（1213）、超时（1205）严格区分。
实际编码中需明确判断：
- ORM 如 MyBatis/Hibernate 可能包装原生异常，丢失错误码语义；建议在 JDBC 层或 DAO 封装中直接检查
SQLException.getSQLState()或getErrorCode() - 不要无限制重试——高并发下密集重试会放大冲突，应配合限流（如令牌桶）或降级（如写入待调度队列）
- 失败后第一反应不是重试，而是查
EXPLAIN：确认是否走索引、是否出现type: ALL或Extra: Using where；全表扫描会锁大量无关行，导致NOWAIT频繁失败
DDL 的 NO_WAIT 和 DML 的 NOWAIT 是两套语法
MySQL 中存在两套“不等待”机制，关键字和作用域完全不同：
- DML 锁定读用
NOWAIT（SELECT ... FOR UPDATE NOWAIT），作用于行级锁，MySQL 8.0.1+ 原生支持 - DDL 操作用
NO_WAIT（如ALTER TABLE ... NO_WAIT），作用于元数据锁（MDL），MySQL 5.7.20+（含 8.0）支持 - 两者不可混用：
ALTER TABLE t ADD COLUMN x INT NOWAIT会报语法错误；SELECT ... FOR UPDATE NO_WAIT同样非法
真正容易被忽略的是锁粒度与执行计划的耦合——NOWAIT 失败往往不是因为目标行被锁，而是扫描路径上某条非目标索引记录被锁住。优化永远从 EXPLAIN 开始，而不是调参或换语法。
