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 的SQLExceptionSQLState 匹配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 里。
