必须将时间过滤条件置于主表（源业务表）外层where子句中，子查询须独立可物化、不含重复键且不引用目标表；否则易致索引失效、漏数据或全量覆盖。
直接在 MERGE 的 USING 子句里写带时间过滤的嵌套子查询是可行的，但必须确保时间条件作用在主表（源业务表），且子查询结果不含重复键、不引用目标表——否则轻则性能暴跌，重则全量覆盖或漏数据。
SQL Server 中 MERGE + 嵌套子查询的正确结构
SQL Server 要求 USING 后的子查询必须是独立、可物化的结果集，不能在子查询里 JOIN 或 WHERE 引用目标表字段（会报错 ERROR 4104）。时间过滤必须落在源表自身字段上，而非关联表。
- ✅ 正确：把增量时间条件放在最外层子查询的
WHERE，例如SELECT * FROM orders WHERE updated_at > @last_time - ❌ 错误：在子查询内层
JOIN order_items ON ... WHERE i.updated_at > @last_time—— 这会让执行计划先算子表再关联，索引失效，还漏掉主表更新但子表未动的记录 - 子查询别名必须显式声明，且所有字段带别名，避免和目标表同名列冲突（如
o.id AS order_id） - 如果子查询含多表
JOIN，务必在ON条件列上建好复合索引，否则MERGE可能因估算偏差选错连接方式，触发哈希匹配或排序溢出
MySQL 里根本不能用 MERGE，得换 INSERT … ON DUPLICATE KEY UPDATE
MySQL 8.0 仍不支持 MERGE 语法，直接写会报 ERROR 1064 (42000)。你看到的“MERGE 效果”实际是 INSERT ... ON DUPLICATE KEY UPDATE 模拟的，它允许嵌套子查询，但有硬性限制：
- 子查询必须出现在
SELECT或VALUES侧，不能出现在ON DUPLICATE KEY UPDATE的表达式里（否则报ERROR 1093） - 子查询不能引用目标表（
INSERT INTO target的target），哪怕只读也不行 - 用
VALUES(col)取值比重复写子查询更安全，例如total_amount = VALUES(total_amount) - 如果源子查询结果中同一唯一键出现多次，MySQL 按顺序逐条处理，但不会报错——行为不可控，务必提前去重
Oracle 和 PostgreSQL 的关键差异点
Oracle 支持完整 MERGE，子查询可嵌套多层，但 ON 条件若匹配多行会直接报错；PostgreSQL 15+ 用 INSERT ... ON CONFLICT 模拟，不支持 USING 后跟任意子查询——尤其不能在 DO UPDATE SET 里调用相关子查询。
- Oracle：可在
WHEN MATCHED THEN UPDATE SET中写子查询，但必须返回单行单列，且不能引用目标表别名（t.col）做外部引用 - PostgreSQL：
ON CONFLICT的DO UPDATE SET不允许子查询，想实现类似逻辑得先用 CTE 预计算，再INSERT ... SELECT - 两者都要求
ON字段有索引，否则MERGE或ON CONFLICT会退化为全表扫描，高并发下极易锁表
参数为空导致全表覆盖的致命陷阱
几乎所有数据库的 MERGE 或类 MERGE 语句，一旦时间参数（如 @last_time 或 :last_time）传入 NULL，WHERE updated_at > NULL 永远为 UNKNOWN，整个 USING 子查询结果为空——WHEN NOT MATCHED 就会把源表全量插入，相当于误删重建。
- SQL Server：执行前加
IF @last_time IS NULL THROW 50000, 'last_time cannot be NULL', 1; - Oracle：用
WHERE updated_at > NVL(:last_time, DATE '1970-01-01')并配合注释说明兜底风险 - MySQL：在应用层校验参数，不把
NULL透传进 SQL - 同步任务成功后，必须立刻把新位点（如最大
updated_at）写入控制表，不能只靠变量临时存——变量一断就丢位点
真正难的不是写出语法正确的嵌套 MERGE，而是让时间条件始终落在主表、让子查询结果稳定可预期、让参数校验嵌入执行链路最前端——这些地方一松懈，凌晨三点的告警就是它发的。
