Oracle MERGE在Java中必须用PreparedStatement，不可拼接字符串；因ON条件、UPDATE/INSERT字段共用同一参数序列，占位符顺序敏感，错位将导致ORA-00913等错误，且需严格对齐字段与参数索引，批量大小建议100–500以平衡性能与资源。
Oracle MERGE 语句在 Java 中必须用 PreparedStatement
直接拼接 sql 字符串执行 merge 极易触发 ora-00900（无效 sql）或绑定变量错位，因为 merge 的 using 子句和 on 条件中变量位置敏感，且 oracle jdbc 驱动对动态 sql 解析严格。必须用 preparedstatement，不能用 statement。
常见错误现象：ORA-00900: invalid SQL statement 或 ORA-00913: too many values，往往是因为占位符 ? 数量与实际参数不匹配，尤其在 WHEN MATCHED THEN UPDATE SET ... 和 WHEN NOT MATCHED THEN INSERT ... 两部分参数混在一起时容易漏数。
-
MERGE语句中所有?按出现顺序从左到右编号，包括ON条件、UPDATE SET列值、INSERT值列表 —— 全部算作一个参数序列 - 如果
ON条件用主键（如id），则该?是第一个参数；后续每个要更新/插入的字段对应一个? - 推荐把
MERGESQL 写成单行字符串（避免换行符干扰），并用注释标出各?对应含义，例如：/* id */ ?, /* name */ ?, /* updated_at */ ?
ON 条件只能基于目标表字段，不能引用 USING 子句别名
Oracle 要求 ON 子句中的字段必须明确属于目标表（即 INTO 后的表），不能写成 USING (...) t ON t.id = target.id 这类写法 —— t.id 在 ON 中不被识别，会报 ORA-00904: "t"."id": invalid identifier。
正确写法是：直接用目标表字段名（可加别名），USING 子句只提供数据源，其字段仅能在 UPDATE SET 和 INSERT 的 VALUES 中通过 USING 别名引用。
- 错误示例：
ON t.id = target.id（t是 USING 别名，不允许出现在 ON 中） - 正确示例：
ON (target.id = ?)，然后在UPDATE SET name = t.name中用t.name - 若需多条件匹配（如按
tenant_id + biz_key联合唯一），全部写在ON中，且所有字段都来自目标表
UPDATE 和 INSERT 的字段列表必须显式对齐，不能依赖 SELECT *
Java 中传入的参数顺序必须与 MERGE 里 UPDATE SET 和 INSERT (...) 的字段顺序完全一致，否则字段值错位 —— 比如把时间戳塞进状态字段，线上数据就乱了。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
常见踩坑点：开发时本地测试用的是小数据集，没暴露字段顺序问题；上线后批量同步时因字段错位导致业务状态被覆盖为默认值（如 status 变成 0）。
-
INSERT (col_a, col_b, col_c) VALUES (?, ?, ?)→ setParameter(1, a); setParameter(2, b); setParameter(3, c) -
UPDATE SET col_b = ?, col_c = ?, updated_at = ?→ 这三个 ? 紧跟在 INSERT 的 ? 之后，继续编号 - 强烈建议封装一个参数索引常量类，比如
IDX_ID = 1, IDX_NAME = 2, IDX_STATUS = 3, IDX_UPDATED_AT = 4，避免硬编码下标
批量执行 MERGE 时，batchSize 控制在 100–500 更稳妥
Oracle 对单次 executeBatch() 的参数总量有限制（尤其当每条 MERGE 绑定多个字段时），超过约 2000 个绑定变量可能触发 ORA-01000: maximum open cursors exceeded 或内存溢出。
不是越大越好：实测在 Oracle 12c/19c 上，单 batch 超过 500 行，JDBC 驱动解析耗时陡增，且事务日志压力大；低于 50 又频繁提交，吞吐反而下降。
- 用
connection.setAutoCommit(false)手动控制事务边界 - 每 100–200 条调用一次
preparedStatement.executeBatch()，再clearBatch() - 最后统一
connection.commit()；失败时rollback()，但注意已执行的 batch 不可回滚，需应用层做幂等补偿
增量同步真正难的不是语法，是字段映射一致性、批量边界控制、以及失败后如何定位哪一行出了错 —— 这些没法靠一条 SQL 解决，得靠参数索引管理和分段日志打点。
