Oracle批量插入快不快，80%取决于ojdbc.jar版本和autoCommit设置；必须用ojdbc8/jdbc11、关autoCommit、设fetchSize=0，再配合INSERT ALL或setArray优化。
Oracle 批量插入快不快，80% 取决于你用的 ojdbc.jar 版本和是否关了 autoCommit——其他所有优化都是在此基础上才生效的。
ojdbc8.jar 或 ojdbc11.jar 是硬门槛，ojdbc6.jar 别碰
Oracle 12c 及以后（包括 19c/21c）的服务器端批处理（Server-Side Batch）能力，只在 ojdbc8.jar（JDK 8+）或 ojdbc11.jar（JDK 11+）中启用。ojdbc6.jar 无论你怎么调 addBatch()，底层仍是客户端模拟，每条语句单独发包，executeBatch() 耗时不会随 batch size 增长而线性改善。
确认方式很简单：
System.out.println(oracle.jdbc.driver.OracleDriver.getMajorVersion());
输出必须是 8 或 11。Maven 里标 “universal” 的旧包，大概率是 ojdbc6.jar 换皮，别信。
立即学习“Java免费学习笔记（深入）”；
addBatch() 必须配合 setAutoCommit(false) 和 setFetchSize(0)
没关自动提交，addBatch() 就是假批量：每次 executeBatch() 都触发完整事务提交，性能退化到逐条插入。
常见错误现象：
- batchSize 设成 5000，但耗时比设 100 还高
- Oracle 侧看到大量短事务、PGA 内存暴涨、甚至报
ORA-04030
正确姿势：
-
connection.setAutoCommit(false)—— 必须在prepareStatement()前调 -
statement.setFetchSize(0)—— 对 INSERT 场景有效，避免驱动额外拉取元数据 - 单批 size 控制在
1000～5000行之间，字段含CLOB/BLOB就往1000靠
INSERT ALL 比 VALUES 多次更省 Oracle CPU
当单条记录字段 ≥ 10 个，拼 1000 条 INSERT INTO t(a,b,c,...) VALUES(?,?,?,...)，Oracle 解析 SQL 的硬解析开销会反超网络节省。换成 INSERT ALL，一条语句塞多行，CPU 压力明显下降。
写法示例（MyBatis 或原生 JDBC 都适用）：
INSERT ALL INTO t(a,b) VALUES(?,?) INTO t(a,b) VALUES(?,?) INTO t(a,b) VALUES(?,?) SELECT * FROM DUAL
注意：
- Oracle 单条
INSERT ALL最多支持约1000个INTO子句，超了得拆批 - MyBatis 中用
<foreach>拼接时，结尾必须加SELECT * FROM DUAL，否则语法报错 - 别用
UNION ALL SELECT方式——它走的是查询路径，不是 DML 路径，性能差一截
setArray() 是真·服务端数组绑定，但限制多
addBatch() 是客户端攒包，setArray() 才真正触发 Oracle 的 Array DML。它把整组参数转成数据库可识别的 ARRAY 类型，一次传入、一次执行，网络开销最小。
但它有硬前提：
- 数据库必须建自定义 TYPE：
CREATE OR REPLACE TYPE str_array AS TABLE OF VARCHAR2(4000) - Java 侧必须用
connection.createArrayOf("STR_ARRAY", stringArray)包装，不能直接setArray(1, stringArray) - 数组元素不能含
null，否则抛SQLException: Invalid column type - 多字段场景下（比如同时绑 id_arr、name_arr、dept_arr），CPU 开销可能高于
INSERT ALL，实测 15 字段 × 1000 行，INSERT ALL快约 40%
所以，setArray() 更适合单字段高频写入（如日志 tag 批量入库），而不是通用宽表插入。
最容易被忽略的一点：executeBatch() 返回的是 int[]，不是布尔值；Statement.EXECUTE_FAILED 表示某条失败，但不会抛异常——漏掉遍历检查，等于批量插入“假装成功”。
