如何解决Oracle存储过程在并发更新同一行数据时的锁超时问题？

不能靠“重试”解决，必须用 SELECT FOR UPDATE WAIT n 显式控制等待边界，确保 WHERE 条件走索引、避免锁升级；因 MERGE/UPDATE 默认无限等待不抛异常，Java 重试逻辑失效，仅显式加锁才能触发可捕获的 ORA-00054 或 ORA-30006 以支撑可控重试。

直接结论：不能靠“重试”解决，必须让锁在业务语义上可预测、可收敛——核心是用 select for update wait n 显式控制等待边界，并确保 where 条件走索引、避免锁升级。

为什么 MERGE 或 UPDATE 会无限阻塞而不报错

Oracle 的 DML（包括 MERGE）默认行为是「无限等待锁释放」，不是超时失败。这意味着 Java 层的 try-catch 捕不到任何异常，重试逻辑完全失效。

• MERGE INTO ... 执行时若目标行已被其他事务加锁，当前会话会静默挂起，直到对方提交或回滚
• JDBC 驱动不会主动中断该等待，除非网络断开或数据库参数 enqueue_resources 耗尽
• 你看到的 ORA-00054 只会在显式使用 NOWAIT 或 WAIT n 时抛出，普通 DML 不触发

SELECT FOR UPDATE WAIT 是唯一可控入口

所有并发更新冲突必须收口到带明确锁语义的查询阶段，否则无法做超时/重试/降级判断。

• 必须用原生 SQL + PreparedStatement，Hibernate 的 setLockMode() 在多数版本中不生成 FOR UPDATE，不可信
• WHERE 条件字段必须有有效索引，用 EXPLAIN PLAN 确认是 INDEX RANGE SCAN，否则可能升级为表锁
• 写法必须是 SELECT ... FOR UPDATE WAIT 3（单位秒），NOWAIT 会导致立即失败，不适合生产重试场景
• MyBatis 中需在 XML 写死 FOR UPDATE WAIT 3，且设置 fetchSize="1"，防止 JDBC 预取多行扩大锁范围

ORA-30006 和 ORA-00054 的捕获与响应

只有显式加锁才产生可捕获的锁超时信号，这是重试策略的唯一依据。

• 捕获 SQLException 后，检查 getSQLState()：值为 61000 表示 ORA-30006（WAIT 超时），getErrorCode() 为 54 表示 ORA-00054（NOWAIT 失败）
• 对 ORA-30006 可做指数退避重试（如 1s → 2s → 4s），但最多 3 轮；超过则降级为异步任务或用户提示“正在排队处理”
• 绝对不要在事务里先 SELECT 再 UPDATE：查到的是旧快照，且没加锁，等于裸奔
• JDBC URL 必须含 oracle.jdbc.readTimeout=0，否则网络抖动可能误杀锁等待

列存表（Columnar Table）要特别警惕 CU 级锁

如果表是列存类型，UPDATE 锁的是整个压缩单元（CU），而非单行——哪怕更新两行不同 ID，只要落在同一 CU 就互斥。

• 用 SELECT ctid FROM table_name WHERE id IN (x,y) 查看是否同属一个 CU（ctid 格式为 (cu_id, offset)）
• 列存表不适合高频点更新，频繁 UPDATE 会不断生成新 CU，空间膨胀快，锁冲突高
• 确认是列存表后，应优先考虑改用行存表，或批量合并更新减少事务频次

真正难的不是加锁语法，而是把锁的边界和等待时间，变成业务流程里可感知、可决策的一环。很多团队卡在“以为重试能解决问题”，结果只是把阻塞从数据库搬到应用线程池里而已。