SQL 悲观锁 FOR UPDATE NOWAIT 的超时处理与业务友好性对比

for update nowait 会立即报错而非等待，因其实现“不等待”语义，遇锁即抛出特定错误（如ora-00054、sqlstate 55p03），需业务层捕获并优雅降级，避免雪崩。

FOR UPDATE NOWAIT 为什么会直接报错而不是等一会儿

因为 NOWAIT 的语义就是“不等待”——只要目标行被其他事务锁住，立刻抛出 Lock wait timeout exceeded 或更具体的 ORA-00054（oracle）、SQLSTATE 55P03（postgresql）这类错误，而不是像默认的 FOR UPDATE 那样挂起当前事务直到锁释放或超时。

这种设计适合对响应时间敏感、能主动降级或重试的场景，比如秒杀库存扣减、订单幂等校验。但代价是业务层必须捕获并处理这个异常，否则请求直接失败。

• mysql 默认等待 50 秒才超时（由 innodb_lock_wait_timeout 控制），加了 NOWAIT 就跳过等待，立刻失败
• PostgreSQL 从 9.5 开始支持 NOWAIT，报错是 SQLSTATE 55P03，不是超时而是“无法获取锁”
• Oracle 用 select ... FOR UPDATE NOWAIT，失败时抛 ORA-00054，不是超时错误

怎么写代码才能不崩又不卡住用户

核心思路是：把“锁失败”当成一种正常业务分支，而不是未处理异常。重点不在重试次数，而在快速识别失败、明确反馈、避免雪崩。

• 在应用层用 try/catch 捕获数据库锁失败异常（如 Python 的 psycopg2.OperationalError，Java 的 SQLException SQLState 匹配 55P03 或 HY000）
• 不要在 catch 里盲目 sleep + retry——这会放大并发压力，且 NOWAIT 本意就是拒绝等待
• 推荐做法：立即返回 {"code": 409, "msg": "资源正被占用，请稍后重试"}，前端可提示“手慢了”，后端可记录日志用于容量分析
• 如果业务允许，可 fallback 到乐观锁（如版本号校验）或异步队列，但需确认一致性边界

NOWAIT 和 LOCK IN SHARE MODE / SELECT FOR UPDATE 的性能差异在哪

差别不在 SQL 执行速度，而在锁粒度和阻塞行为带来的吞吐影响。

• FOR UPDATE NOWAIT：不阻塞，但失败率高；适合短事务、高并发、可容忍部分失败的场景（如抢购）
• FOR UPDATE（无 NOWAIT）：可能长时间挂起连接，拖慢整个连接池，容易引发级联超时
• LOCK IN SHARE MODE（MySQL）或 SELECT ... FOR SHARE（PostgreSQL）：允许多个读，但阻塞写；若业务只需读+防写覆盖，比排他锁更轻量
• 注意：InnoDB 中 FOR UPDATE 在 RC 隔离级别下只锁命中行，但如果有间隙锁（如范围查询），NOWAIT 同样会因间隙被占而失败

最容易被忽略的兼容性坑

不同数据库对 NOWAIT 的支持程度和错误码不统一，硬编码判断很容易漏掉一种情况。

• MySQL 8.0.1 以上才支持 NOWAIT，5.7 及之前不识别该关键字，直接报语法错误 ERROR 1064
• PostgreSQL 支持但要求显式写 FOR UPDATE NOWAIT，不能只写 NOWAIT；而且 FOR NO KEY UPDATE NOWAIT 是更细粒度的变体
• SQL Server 没有 NOWAIT，对应的是 WITH (UPDLOCK, NOWAIT) 提示，错误码是 1205（死锁）或 1222（锁超时），语义不完全等价
• ORM 如 SQLAlchemy、mybatis 需检查是否生成了正确的方言 SQL，有些版本会静默忽略 NOWAIT

真正麻烦的不是语法，而是你在线上切到新数据库或升级版本后，原来兜底的异常捕获逻辑突然不生效了——因为错误类型变了，或者根本没走到 catch 里。