SELECT ... FOR UPDATE NOWAIT 在高并发下的死锁规避写法_网络技术

发布时间 - 2026-01-31 00:00:00 点击率：次

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 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 解决的从来不是“要不要锁”，而是“锁不到时怎么办”——它把数据库的阻塞决策权，移交给了你写的重试逻辑和加锁策略。