Oracle更新无报错但未生效的四大主因：变量名与字段名冲突致WHERE恒真/假；行锁/表锁阻塞导致executeUpdate()挂起；事务未显式commit或异常路径遗漏rollback；PreparedStatement批处理返回-2被误判失败。
Java端执行Oracle更新语句没报错但没生效，基本不是SQL写错了，而是被Oracle的隐式规则“静默拦截”了——常见于变量名冲突、锁阻塞、事务未提交、批处理降级这四类场景。
Oracle存储过程中变量名与字段名相同导致UPDATE失效
这是最隐蔽也最高频的问题：存储过程里定义的变量名（如 code）和表字段名（如 code）完全一致，Oracle解析时优先绑定到字段而非变量，WHERE x.code = code 实际变成 WHERE x.code = x.code，恒为真或恒为假，整条UPDATE逻辑失效，但语法合法、不报错、返回0行影响。
- 只要变量名和同名字段出现在同一作用域（非参数），就会触发该行为；参数名即使同名也安全
- CHAR类型字段还需注意长度隐式填充空格，
'100'和'100 '比较不等价 - 统一加前缀是硬性习惯：
p_code（参数）、v_code（变量）、t_code（临时）
UPDATE卡住无响应，实为行锁/表锁阻塞
Java线程停在executeUpdate()不返回，PL/SQL里执行同样SQL也“正在执行”，但SELECT正常——八成是目标行被其他会话锁住且未提交，当前会话无限等待。
- 查锁：运行
SELECT T1.ORACLE_USERNAME, T2.SID, T2.SERIAL# FROM V$LOCKED_OBJECT T1, V$SESSION T2 WHERE T1.SESSION_ID = T2.SID - 杀锁：用查出的
SID和SERIAL#执行ALTER SYSTEM KILL SESSION 'sid,serial#' - 预防关键点：Java事务必须显式
commit()或rollback()；PL/SQL调试完务必手动提交，别靠关闭窗口自动回滚
PreparedStatement批量更新后getUpdateCounts()全为-2，误判为失败
executeBatch() 返回的 int[] 全是 -2，不代表没执行，而是Oracle JDBC驱动严格遵循JDBC规范，返回 Statement.SUCCESS_NO_INFO ——它不提供每条语句的真实影响行数。
立即学习“Java免费学习笔记（深入）”；
- 拿
-2做业务判断（比如“必须全部 > 0 才算成功”）必然出错 - 真正失败时抛的是
BatchUpdateException，但它的getMessage()往往只显示“could not execute JDBC batch update”，真实错误码（如ORA-00001）藏在getNextException()里 - 必须复用同一个
PreparedStatement实例调用所有addBatch()，否则降级为单条执行，且不报任何提示
自动提交未关闭 + 未手动commit()，事务悬而未决
Connection默认开启自动提交（autoCommit=true），但一旦你调用了 setAutoCommit(false)，后续所有DML都进入事务上下文——若忘了 commit()，数据就一直停留在UNCOMMITTED状态，对其他会话不可见，看起来就是“没更新”。
- 检查代码是否在
executeUpdate()后遗漏了connection.commit() - 更危险的是异常路径：try-catch里只打印日志却没
rollback()，连接还可能被归还连接池，导致脏数据长期滞留 - Spring中
@Transactional失效的常见原因：方法非public、自调用（this.method()）、代理未生效、异常被吞
这些情况都不会抛出明显异常，日志里连SQL都打印得清清楚楚，但数据就是不动。排查时优先看锁、再核变量命名、接着确认事务边界，最后才怀疑SQL本身——因为Oracle对语法错误向来毫不留情，报错才是常态，不报错反而是线索。
