ojdbc8/jdbc11驱动、setAutoCommit(false)、单批1000～5000行是Oracle万级批量插入性能关键；需检查executeBatch返回值、避免索引/约束影响、禁用fetchSize冗余开销。
用 addbatch + executebatch 插入万级数据到 oracle，性能差多半不是写法问题，而是驱动、配置或事务控制没对上。直接上结论：ojdbc8.jar（jdk 8+）或 ojdbc11.jar（jdk 11+）是硬门槛，setautocommit(false) 是生死线，单批 1000～5000 行是实测安全区间。
ojdbc 驱动版本不匹配会导致 executeBatch 彻底失效
Oracle 12c 及以后（包括 19c/21c）的批量优化依赖 JDBC 驱动的 Server-Side Batch 支持，这在 ojdbc6.jar 中根本不存在——它只能走客户端模拟，每条 addBatch 实际仍发一次网络包。你看到的“批量”只是假象。
- 确认方式：
System.out.println(oracle.jdbc.driver.OracleDriver.getMajorVersion())输出必须是8或11 - Maven 里标 “universal” 的 ojdbc6 包别信，重命名不等于功能升级
- Spring Boot 3.3 + JDK 17 推荐直接用
ojdbc11.jar，Maven 坐标 groupId 是com.oracle.database.jdbc
不关 autoCommit 就别谈批量插入
setAutoCommit(true) 下调 executeBatch()，等价于手动执行 N 条单条 INSERT 并逐条提交——连接池可能都帮你 commit 了，你还以为在批量。
- 必须在
prepareStatement前调用connection.setAutoCommit(false) - batch 执行完必须显式
connection.commit()，不能靠连接关闭或连接池回收 - 异常时要
connection.rollback()，否则事务卡住，后续操作可能被阻塞
单批 size 和 fetchSize 直接影响 Oracle 内存与成功率
Oracle PGA 不是无限的，单批太大容易触发 ORA-04030（内存耗尽），太小又浪费网络往返。实测 1000～5000 是平衡点，但得看单行数据体积。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 建议起始值设
2000，根据实际单行大小动态下调（比如字段含 CLOB/BLOB 就往 1000 靠） - 超过
5000行后性能非线性下降，某些场景下6500就开始丢数据（如你看到的 CSDN 示例里“6万5千是极限”其实是误判，那是总数据量，不是单批） - 加一句
statement.setFetchSize(0)，避免 Oracle JDBC 驱动额外拉取元数据，对 insert 场景有效
executeBatch 返回值必须检查，不能只看是否抛异常
Oracle 批量执行默认是 all-or-nothing，但 JDBC 层返回的是 int[]，其中 Statement.EXECUTE_FAILED 表示某条失败，而不会主动 throw 异常——你漏掉这个判断，就等于假装成功。
立即学习“Java免费学习笔记（深入）”；
- 每次
executeBatch()后立即遍历返回数组：for (int i = 0; i - 如果业务允许部分失败（比如跳过脏数据），就别用 batch，改用单条
executeUpdate+ try-catch - INSERT ALL 方式更适合字段多（>10 列）的场景，一条 SQL 塞多行，硬解析压力小；但注意单语句最多支持约 1000 个
INTO子句，超了得拆批
最常被忽略的一点：表结构本身。没有索引的空表跑得飞快，但加了唯一约束或外键后，每批的校验开销会陡增——上线前务必在相同 DDL 环境下压测，而不是只在测试库的无索引表上验证。
