Oracle的PreparedStatement批量更新返回-2是符合JDBC规范的正常行为，表示执行成功但影响行数未知；真正问题常源于异常未穿透、自动提交未关闭、PreparedStatement未复用或SQL不规范导致批处理降级。
Java 使用 PreparedStatement 批量更新 Oracle 本身不会“失效”，但你观察到的“没更新”“返回 -2”“部分失败不报错”等现象，基本都源于 JDBC 驱动行为、Oracle 实现限制或代码误用——不是功能坏了，而是没按 Oracle 的规则用。
Oracle 的 executeBatch() 根本不返回真实影响行数
调用 executeBatch() 后拿到 int[] 数组，全是 -2，这不是 bug，是 JDBC 规范定义的合法值：Statement.SUCCESS_NO_INFO。Oracle JDBC 驱动明确不支持从 PreparedStatement 批处理中获取每条语句的实际影响行数。
- MySQL 驱动能返回具体数字，是因为它“越界”实现了非标准行为；Oracle 严格遵循 JDBC 2.0，只保证“执行成功”，不承诺“告诉你改了几行”
-
getUpdateCounts()返回-2不代表失败，也不代表没执行——它只是说“我不知道” - 若你用这个数组做业务判断（比如“必须全部 > 0 才算成功”），逻辑就错了
批处理失败时异常被吞掉，BatchUpdateException 需手动穿透
Oracle 批处理出错（如主键冲突、字段超长、ORA-01722 类型转换失败），executeBatch() 抛出的是 BatchUpdateException，但它的 getMessage() 常只有 “could not execute JDBC batch update”，底层真实的 ORA-xxxx 被藏在嵌套异常里。
- 必须显式调用
getNextException()才能拿到第一个失败语句对应的原始错误 - 如果只 catch
SQLException并打印 getMessage()，你会以为“一切正常”，实际部分数据已静默丢弃 - MyBatis 的
BatchResult.getUpdateCounts()就是基于这个机制封装的，所以它也拿不到真实计数或具体失败位置
批量更新语句本身被优化器拒绝执行
Oracle 对批处理语句的解析和执行路径，高度依赖绑定变量类型、SQL 文本稳定性、驱动参数。以下情况会导致看似执行了，实则被跳过或降级为单条执行：
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
立即学习“Java免费学习笔记（深入）”；
-
SetBigStringTryClob=true：把 String 绑定成 CLOB，而目标字段是 VARCHAR2，触发隐式转换 → 索引失效 → 优化器可能直接拒绝批处理计划，回退到逐行执行（但不报错） - SQL 中混用字面量和参数（如
WHERE status = 'ACTIVE' AND id = ?），破坏 SQL 文本一致性 → 游标无法共享 → 批处理缓存失效 - 未关闭自动提交（
connection.setAutoCommit(false)）又没手动commit()，事务未结束，看起来“没更新”
复用 PreparedStatement 实例是硬性前提
批量操作生效的前提，是所有 addBatch() 都发生在同一个 PreparedStatement 实例上。常见误用是循环里反复 connection.prepareStatement(sql)，每次新建实例：
- 前一个实例的 batch 缓存不会自动合并到下一个实例，
executeBatch()只会执行当前实例里 add 过的那几条 - 表面看写了 100 次
addBatch()，实际分成了 100 个单条批次，性能归零，还容易触发连接/游标泄漏 - 正确做法：prepare 一次，循环 setParameter + addBatch，最后统一 executeBatch
最常被忽略的一点：Oracle 批处理的“成功”只意味着语句发出去且数据库接受了，不代表业务逻辑成立。验证是否真更新了，不能靠 getUpdateCounts()，得靠主键查、COUNT 对比、或者设计幂等写入逻辑——这才是生产环境真正兜底的方式。
