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会隐式开启事务，但语句执行完立刻提交、释放锁，后续UPDATE没锁保护，极易并发覆盖 - 常见误判：应用看到没报错就以为“拿到了锁”，实际可能根本没锁住任何行
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。混用异常处理逻辑会导致重试错乱甚至数据错乱。
-
$pdo->errorInfo()[1] === 3572（PHP PDO） - Java JDBC 需捕获
SQLState HY000并比对getErrorCode() == 3572 - 不能把
3572当作“数据库异常”统一熔断或告警——它是预期中的快速失败路径 - 误捕获为通用 SQL 错误后直接返回 500，等于把“抢不到资源”当成系统故障，掩盖了真实业务瓶颈
NOWAIT 不能用于 UPDATE/DELETE，且与 SKIP LOCKED 互斥
NOWAIT 仅支持 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)中的NOWAIT不传导，外层也没加锁 - 在视图、UNION 或非锁定读中使用
NOWAIT，均提示不支持
真正容易被忽略的点在于：NOWAIT 报错不等于“没查到数据”，而极可能是锁落在了非目标行但被扫描到的索引记录上——比如查询条件没走索引，触发全表扫描，就会对所有扫描过的行加意向锁；哪怕你只想要 id = 100，也可能因扫描了 1 万行而被其中任意一行的锁挡住。所以报错后第一反应不该是重试，而是查 EXPLAIN 和索引设计。
