NOWAIT使SELECT FOR UPDATE在无法获取行锁时立即报ERROR 3572，而非等待超时；它仅作用于显式事务中的行级锁，需应用层捕获该错误并重试或降级。
因为NOWAIT让“抢不到就立刻知道”，而不是卡在数据库连接里干等几十秒。
NOWAIT 本质是取消等待，不是缩短等待
默认的 SELECT ... FOR UPDATE 在目标行被锁时会阻塞，直到锁释放或触发 ERROR 1205（死锁）或 ERROR 1206（锁等待超时），而后者依赖 innodb_lock_wait_timeout（默认 50 秒）。NOWAIT 不走这套逻辑：只要行锁拿不到，毫秒级内直接返回 ERROR 3572 (HY000)，连接立刻释放，线程不挂起。
- 它不修改任何超时参数，也不影响其他语句行为
- 它只作用于当前这条
SELECT ... FOR UPDATE NOWAIT或SELECT ... FOR SHARE NOWAIT语句 - 失败不是异常，而是设计结果——应用层应明确捕获
3572，而非兜底 catch 所有 SQL 错误
必须显式开启事务，否则 NOWAIT 形同虚设
NOWAIT 只在显式事务中生效。如果 autocommit = 1（默认），执行 SELECT ... FOR UPDATE NOWAIT 会隐式开启一个事务，但该事务在语句结束时自动提交，锁也随即释放——这意味着后续的 UPDATE 操作完全没锁保护，业务逻辑直接断裂。
- 正确做法：先
START TRANSACTION或SET autocommit = 0 - 再执行
SELECT id, stock FROM items WHERE id = 123 FOR UPDATE NOWAIT - 拿到数据后做校验，再执行
UPDATE，最后COMMIT或ROLLBACK - 漏掉
START TRANSACTION是线上最常见、最难排查的坑之一
报错不等于没查到数据，很可能是索引没走对
ERROR 3572 的真实原因，常不是“你要的那行被锁了”，而是“你扫描过程中碰到的某一行被锁了”。比如 WHERE status = 'pending' 没走索引，导致全表扫描，InnoDB 对每条扫描到的记录加意向锁；哪怕你要的那条记录根本没被锁，也会因中间某条无关记录被锁而失败。
- 务必用
EXPLAIN SELECT ... FOR UPDATE NOWAIT看执行计划 - 重点检查
type是否为ALL、key是否为空、Extra是否含Using where - WHERE 条件列必须有高效索引（主键、唯一键、覆盖索引优先）
- 复合索引要注意最左匹配，避免因顺序错失索引
NOWAIT 不能用于 UPDATE/DELETE，也不能和 SKIP LOCKED 共存
很多人想当然地写 UPDATE ... NOWAIT 或 SELECT ... FOR UPDATE NOWAIT SKIP LOCKED，这两种写法都非法：
-
NOWAIT语法只被SELECT ... FOR UPDATE和SELECT ... FOR SHARE支持，UPDATE/DELETE不接受锁提示 -
NOWAIT和SKIP LOCKED语义冲突：前者要求“全有锁就失败”，后者要求“有锁就跳过”，MySQL 明确禁止二者共用 - 子查询里加
NOWAIT无效，例如SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 FOR UPDATE NOWAIT)—— 外层无锁，子查询的NOWAIT不传导
真正难的是把 NOWAIT 融进业务流程：它不解决“怎么抢”，只解决“抢不到时别卡住”。应用层得配套实现快速重试、降级响应（如“已抢光”）、异步排队等逻辑，否则只是把数据库等待，换成了应用层空转。
