SELECT FOR UPDATE NOWAIT 必须显式开启事务才生效，否则静默降级为普通读；仅对行级记录锁有效，不响应间隙锁；失败固定返回ERROR 3572，需应用层精准捕获，且仅支持SELECT...FOR UPDATE/SHARE语法。
SELECT FOR UPDATE NOWAIT 必须显式开启事务才生效
不开启事务时，SELECT ... FOR UPDATE NOWAIT 会被 MySQL 静默降级为普通读，既不加锁也不报错，但 NOWAIT 完全失效。这不是 bug，是设计行为。
- 必须先执行
START TRANSACTION或SET autocommit = 0，再执行带NOWAIT的锁定读 - 自动提交模式下（
autocommit = 1），单条FOR UPDATE NOWAIT会隐式开启事务，但语句执行完立刻提交、释放锁——后续更新没锁保护，极易引发并发覆盖 - 常见误判：应用层看到没报错就以为“拿到了锁”，实际可能根本没锁住任何行
NOWAIT 只对行级记录锁有效，对间隙锁完全无感
NOWAIT 不是万能开关，它只响应 InnoDB 的 record lock（记录锁），对 gap lock（间隙锁）和 next-key lock（临键锁）不触发立即失败。这意味着：WHERE 条件若没走索引、或命中非唯一二级索引，很可能因间隙锁阻塞而仍卡住，NOWAIT 不起作用。
- 用
EXPLAIN SELECT ... FOR UPDATE NOWAIT确认type是const或ref，避免出现ALL或index - 检查
Extra字段：含Using where通常意味着走了全索引扫描，锁范围远超目标行 - 主键/唯一索引查询最安全；非唯一索引 +
FOR UPDATE极易触发间隙锁，此时NOWAIT无效
应用层必须专门捕获 ERROR 3572，不能泛化处理
NOWAIT 失败返回的是固定错误码 ERROR 3572 (HY000)，不是 ERROR 1205（Lock wait timeout exceeded），也不是死锁错误 ERROR 1213。混用异常处理逻辑会导致重试逻辑错乱甚至数据错乱。
- PHP 中需检查
$pdo->errorInfo()[1] === 3572；Java JDBC 需捕获SQLState HY000并比对getErrorCode() == 3572 - 不能把
3572当作“数据库异常”统一熔断或告警——它是预期中的快速失败路径 - 误捕获为通用 SQL 错误后直接返回 500，等于把“抢不到资源”当成系统故障，掩盖了真实业务瓶颈
NOWAIT 不能和 SKIP LOCKED 共存，也不能用于 UPDATE/DELETE
语法上 NOWAIT 和 SKIP LOCKED 互斥，MySQL 直接报错；且它仅支持 SELECT ... FOR UPDATE NOWAIT 和 SELECT ... FOR SHARE NOWAIT，其他语句加 NOWAIT 会被忽略或报错。
-
UPDATE ... WHERE ... NOWAIT语法错误，MySQL 提示Unknown syntax -
SELECT ... FOR UPDATE NOWAIT和SELECT ... FOR UPDATE SKIP LOCKED同时出现，报错Unsupported use of FOR UPDATE NOWAIT - 子查询里写
NOWAIT（如SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 FOR UPDATE NOWAIT)）无效，外层不继承锁提示
真正难的不是写对那行 SQL，而是确认你锁的到底是哪几行——NOWAIT 报错时，90% 的问题出在执行计划没走索引，或者你以为锁的是 id=100，实际锁了一整个索引区间。
