Oracle Merge Into执行慢，大概率不是语句本身的问题：MERGE INTO本身高效，慢因多在JDBC驱动版本低、fetchSize不当、ON条件未走索引、Java层伪批量循环执行或执行计划退化。
Oracle Merge Into执行慢，大概率不是语句本身的问题
直接说结论：MERGE INTO 本身在 Oracle 中是高效操作，尤其比先 SELECT 判断再 INSERT/UPDATE 要快得多。Java 程序里跑得极慢，90% 以上情况出在 JDBC 层或执行上下文，而不是 SQL 逻辑。
JDBC 驱动版本和 fetch size 会显著拖慢 MERGE 执行
Oracle 官方 JDBC 驱动（ojdbc8.jar 及以上）对 MERGE 的批量处理支持良好，但老版本（如 ojdbc6）或某些国产连接池（如早期 Druid）可能把 MERGE 当作普通 DML 处理，不启用内部优化路径。更隐蔽的是 fetchSize 设置——哪怕你只执行一条 MERGE，如果 PreparedStatement 被设了 setFetchSize(10)，驱动可能强行分批拉取元数据或触发额外 round-trip。
- 检查驱动版本：运行
System.out.println(oracle.jdbc.driver.OracleDriver.getMajorVersion())，确保 ≥ 12（对应 ojdbc8） - 显式关闭自动 fetch：调用
ps.setFetchSize(0)或不设（默认为 0） - 避免在
MERGE前后混用ResultSet操作，防止驱动误判为查询语句
ON 条件没走索引，Merge 就退化成嵌套循环
MERGE 的性能核心在 ON 子句的关联效率。如果 USING 子句来源是大表或子查询，且 ON (t1.id = t2.id) 中任意一边的字段没索引，Oracle 会回退到全表扫描 + NESTED LOOPS，此时执行计划里会出现大量 TABLE ACCESS FULL 和高 consistent gets。实测中，一个 50 万行的 USING 表，若 ON 字段无索引，MERGE 耗时可比有索引时高出 20 倍以上。
- 用
EXPLAIN PLAN FOR MERGE ...查看实际执行计划，重点看ACCESS PREDICATES是否命中索引 -
USING若是子查询，确保其结果集已通过物化视图或临时表预建索引 - 避免在
ON中写函数，例如ON (UPPER(t1.code) = t2.code)，会直接让索引失效
Java 层批量提交策略不当，放大网络与事务开销
很多人以为 MERGE 天然支持批量，其实单条 MERGE 只能处理一个 USING 源。如果你 Java 里循环执行 1000 次 MERGE INTO t USING (SELECT ? id, ? name FROM dual) s ON ...，等于发了 1000 次网络请求、1000 次硬解析、1000 次事务日志刷盘——这比用 addBatch() 批量插入还慢。
立即学习“Java免费学习笔记（深入）”；
- 把多条记录塞进一个
USING：用SELECT ... FROM dual UNION ALL SELECT ... FROM dual，或 Oracle 23ai 起支持的VALUES (),( ),...构造函数 - 禁用自动提交：
conn.setAutoCommit(false)，所有MERGE合并在一个事务里 - 慎用
RETURNING子句：它会强制驱动拉取结果集，即使你不需要返回值
真正卡住的地方，往往不在 MERGE 关键字本身，而在你没意识到的驱动行为、执行计划退化或 Java 层的“伪批量”写法。查 v$sql 看 EXECUTIONS 和 ELAPSED_TIME，比盯着 Java 日志更有说服力。
