这种批量插入的不一致性确实挺头疼的，尤其是已经排除了外键、触发器这些常见卡点之后。结合你用的Java + Spring Batch + OJDBC7（v12.1.0.2）环境，我从几个核心方向给你梳理排查思路：

1. 先确认Spring Batch的Chunk与Writer配置是否真的“全局一致” #

• 检查慢表对应的JdbcBatchItemWriter是否继承了全局的batchSize=1000配置？有没有针对特定表的自定义Writer，不小心把batchSize改小了？
• 别忽略flushInterval参数：Spring Batch的JdbcBatchItemWriter如果设置了flushInterval，它会优先按这个值触发提交，而不是batchSize。比如如果flushInterval=1，那哪怕batchSize=1000，也会单行提交。
• 排查容错配置：如果开启了skip-limit或retry-limit，当某一行插入失败时，Spring Batch可能会自动拆分Chunk，把失败的行单独重试，这就会导致v$sql里出现单行/小批次的执行记录。可以查看日志里有没有重试/跳过的相关日志。

2. 深挖OJDBC驱动的批量处理“暗箱操作” #

OJDBC的批量行为有时候会和你预期的不一样，尤其是针对特殊字段或未正确配置参数时：

• 检查defaultBatchValue参数：OJDBC7默认的defaultBatchValue是1，也就是说如果不显式设置，驱动可能不会自动批量提交。你需要在JDBC URL里加上oracle.jdbc.defaultBatchValue=1000，或者在代码里给PreparedStatement设置setBatchSize(1000)。
• 排查大字段影响：如果慢表包含CLOB/BLOB/LONG类型的字段，OJDBC对这类字段的批量处理有特殊逻辑，可能会自动拆分批次甚至 fallback 到单行执行。可以尝试临时把大字段注释掉，测试插入速度是否恢复正常；或者调整驱动参数oracle.jdbc.useFetchSizeWithLongColumn=true（针对LONG字段）。
• 开启驱动日志：添加oracle.jdbc.Trace=true到JDBC URL，查看驱动实际发送给Oracle的批次大小，确认是不是真的按1000行批量提交的。

3. 检查Oracle端的“隐式约束与状态” #

虽然你已经关闭了外键和触发器，但还有一些容易忽略的点：

• 确认外键的VALIDATE状态：即使外键DISABLE了，如果还是VALIDATE状态，Oracle在插入时依然会做隐式的约束检查。可以用这条SQL确认：

  SELECT constraint_name, status, validation 
  FROM user_constraints 
  WHERE table_name = '你的慢表名' AND constraint_type = 'R';
  

  如果validation='VALIDATE'，执行ALTER TABLE 慢表名 DISABLE NOVALIDATE CONSTRAINT 外键名;关闭验证。
• 刷新表统计信息：如果慢表的统计信息过期，Oracle优化器可能会选择低效的执行计划，甚至放弃批量插入。手动收集统计信息试试：

  EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => '你的用户', TABNAME => '慢表名', CASCADE => TRUE);
  

• 排查锁等待：有没有其他进程在操作慢表，导致你的批量插入被阻塞？查询锁状态：

  SELECT s.sid, s.serial#, s.wait_class, s.wait_time, l.type, l.id1, l.id2 
  FROM v$session s 
  JOIN v$lock l ON s.sid = l.sid 
  WHERE s.username = '你的ETL用户' AND s.status = 'ACTIVE';
  

  如果看到enq: TX - row lock contention这类等待事件，说明有锁冲突。

4. 分析SQL Trace里的关键细节 #

从你提供的SQL Trace里，重点关注这几个点：

• 看EXECUTE语句的rows字段，以及绑定变量的数量：如果每次执行的绑定变量数远小于1000，说明驱动/框架没有把1000行打包成一个批次。
• 检查等待事件：慢表的插入是不是有大量的db file sequential read（IO瓶颈）、log file sync（日志写入慢）等等待？这些能直接指向性能卡点。
• 对比快表和慢表的Trace：看执行流程的差异，比如快表是不是用了array bind批量提交，而慢表是单行执行？

5. 做个最小化验证 #

写一个极简的Java程序，跳过Spring Batch，直接用OJDBC批量插入慢表1000行，然后查v$sql看执行行数：

// 伪代码
String sql = "INSERT INTO 慢表名 (col1, col2) VALUES (?, ?)";
try (Connection conn = DriverManager.getConnection(url, user, pwd)) {
    conn.setAutoCommit(false);
    PreparedStatement pstmt = conn.prepareStatement(sql);
    for (int i = 0; i < 1000; i++) {
        pstmt.setString(1, "test" + i);
        pstmt.setInt(2, i);
        pstmt.addBatch();
    }
    pstmt.executeBatch();
    conn.commit();
}

如果这个测试里v$sql显示执行行数是1000，那问题大概率出在Spring Batch的配置或逻辑里；如果还是单行/小批次，那就是OJDBC驱动或Oracle端的问题。

内容的提问来源于stack exchange，提问作者Dean Clark