select … for UPDATE NOWaiT 不防死锁，但能快速暴露死锁：事务申请锁失败时立即报错而非等待，避免环形等待；需配合统一加锁顺序、缩小锁范围和应用层指数退避重试。
SELECT … FOR UPDATE NOWAIT 为什么能防死锁？
它本身不防死锁，但能快速暴露和中断潜在死锁链——NOWAIT 让事务在拿不到锁时立刻报错（如 ORA-00054: Resource busy 或 Error: could not obtain lock），而不是无限等待。这避免了“多个事务互相卡住等对方释放锁”的经典环形等待场景。
关键点在于：死锁检测有开销，而 NOWAIT 把“等待→超时→回滚→重试”的过程提前到锁申请阶段，把隐性死锁转化成显性失败，交由应用层控制重试逻辑。
高并发下必须配合的三件事
只加 NOWAIT 不够，容易变成高频报错却不解决问题。真正落地要同步做：
- 统一加锁顺序：比如所有涉及订单+库存的事务，强制先
SELECT ... FROM inventory FOR UPDATE NOWAIT，再SELECT ... FROM orders FOR UPDATE NOWAIT；交叉顺序是死锁温床 - 缩小锁范围：确保
WHERE条件命中索引，否则 mysql/oracle 可能升级为表锁，NOWAIT也救不了并发吞吐 - 应用层兜底重试：捕获
resource busy类错误后，用指数退避（如 10ms → 30ms → 100ms）重试，最多 3 次；别裸 throw
MySQL vs Oracle 的 NOWAIT 行为差异
语法相似，但底层处理不同，容易踩坑：
- MySQL 8.0.1+ 才原生支持
NOWAIT；低版本只能用SELECT ... FOR UPDATE WAIT 0模拟（注意：WAIT 0 是 MySQL 特有，Oracle 不认） - Oracle 中
NOWAIT错误固定是ORA-00054；MySQL 是ERROR 1205 (HY000): Deadlock found when trying to get lock或更细粒度的锁冲突提示 - postgresql 同样支持
NOWAIT，但错误码是55P03（could not obtain lock），且SKIP LOCKED在分页抢购类场景比NOWAIT更实用
一个典型错误写法及修正
常见反模式：在未确认业务语义前提下，给全表扫描加 NOWAIT ——比如 SELECT * FROM user_balance WHERE status = 'pending' FOR UPDATE NOWAIT，但 status 没索引，实际触发表级锁，所有并发请求立刻失败。
正确做法：
- 先加索引：
CREATE INDEX idx_user_balance_status ON user_balance(status) - 改用精准条件：
SELECT * FROM user_balance WHERE user_id = ? AND status = 'pending' FOR UPDATE NOWAIT - 如果真要批量处理 pending 记录，用
SKIP LOCKED分片取数，而非NOWAIT硬扛
最易被忽略的是：NOWAIT 解决的从来不是“要不要锁”，而是“锁不到时怎么办”——它把数据库的阻塞决策权，移交给了你写的重试逻辑和加锁策略。