Oracle PreparedStatement批处理需关闭自动提交、设合理批大小（建议20）、避免缓存不执行，并升级至21c+驱动以提升性能。
直接开干：oracle 的 preparedstatement 批处理不是“开了就快”，必须关掉自动提交、控制批大小、适配 oracle 驱动特性，否则可能比单条还慢。
为什么 setAutoCommit(false) 是硬性前提？
Oracle 默认每条 executeUpdate() 都触发一次网络往返 + 事务日志刷盘。2000 条记录开启自动提交时耗时约 11.7 秒；关闭后仅需 3.5 秒——差出三倍以上。
- 必须在
PreparedStatement创建前调用conn.setAutoCommit(false) - 不能只靠
addBatch()就以为“自动进批”，没关自动提交，每条executeBatch()实际仍是独立事务 - 忘记
commit()会导致连接长期持锁，后续查询被阻塞
batchSize 设多少才合适？
Oracle 官方建议 5–30 行为最优区间，和 MySQL/PostgreSQL 的“越大越好”逻辑完全不同。实测 100 行批处理在 Oracle 上反而比 10 行慢 12%——因为驱动层内部会拆包重路由，且容易触发 PGA 内存溢出。
- 通用起步值设
20，再根据实际字段数微调：字段超 50 个时降到10，纯 ID+状态字段可试30 - 别依赖
executeBatch()返回的int[]数组做逐条成功判断——Oracle 批处理失败是整批回滚，返回值全为-3（EXECUTE_FAILED） - 如果用的是
OraclePreparedStatement（非标准接口），可用setDefaultExecuteBatch(20)让驱动自动攒批，但仅限 Oracle JDBC driver 12c+
addBatch() 后不 executeBatch() 的常见陷阱
缓存不执行 = 白攒。很多代码把 addBatch() 放在循环里，却把 executeBatch() 错写在循环外或异常分支里，导致最后只执行了最后一次的 batch。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 推荐模式：每
batchSize次调用addBatch()后立即executeBatch()，再clearBatch() - 别在
for循环末尾统一执行——内存占用随数据量线性增长，10 万条可能 OOM - 若需全部插入完再 commit，
executeBatch()可多次调用，只要中间不commit()，事务仍保持打开
Oracle 特有优化项：defineColumnType 和 setRowPrefetch
这两项不改不影响批处理运行，但能减少类型推断和结果集拉取开销——尤其当你批量插入后立刻查刚插的数据做校验时。
立即学习“Java免费学习笔记（深入）”；
-
defineColumnType(1, Types.VARCHAR)告诉驱动第 1 列是字符串，避免每次从数据库元数据反查 Java 类型 -
setRowPrefetch(50)（注意是OracleStatement方法，不是标准setFetchSize）让驱动一次从服务器拉 50 行，对批量 insert 后的 select count(*) 类操作提速明显 - 这两项必须在
executeBatch()前设置，之后设置无效
最容易被忽略的一点：Oracle 的批处理性能高度依赖驱动版本。JDBC 11g 驱动对 addBatch() 的参数序列化有额外拷贝开销，升级到 21c 或 23ai 驱动后，同一批大小下吞吐能提升 35% 以上——别卡在老驱动上空调参数。
