SQL MERGE 本身不支持直接对多个目标表进行更新，它只允许一个 target table（目标表），但可以通过巧妙设计源数据来实现“类多表更新”的效果。关键在于：把需要联动更新的多张表的变更逻辑，统一收敛到一个主表的变更驱动上，并用子查询、CTE 或临时结果集构造出完整的源数据视图。
用 CTE 预聚合多表变更逻辑
当要根据同一业务主键（如 order_id）同时更新 orders、order_items、customers 三张表时，不要写三个 MERGE，而是先用 CTE 把各表需更新的字段组装成一张逻辑“源表”：
- 在 CTE 中 JOIN 多张表，筛选出需更新的记录，并计算出每张表各自要设的新值（如 customers.status = 'shipped'，order_items.quantity = order_items.quantity - 1）
- 主 MERGE 的 USING 子句引用该 CTE，ON 条件匹配主键；WHEN MATCHED THEN UPDATE 只作用于单个目标表（比如先更新 orders），其他表的更新通过触发器、后续语句或应用层协同完成
- 若必须原子性更新多表，MERGE + 事务更稳妥：BEGIN TRAN → MERGE orders → UPDATE order_items → UPDATE customers → COMMIT
用子查询构造动态 source 数据
源数据不必是物理表，可以是带计算列和条件逻辑的子查询，这对跨表派生更新值非常实用：
- 例如：要把 user_profiles 中的 last_login_time 更新为 users 表中最新登录时间，同时把 is_active 设为 users.status = 'active' —— 直接在 USING 后跟 (SELECT u.id, MAX(l.login_time), CASE WHEN u.status='active' THEN 1 ELSE 0 END FROM users u LEFT JOIN logins l ON u.id=l.user_id GROUP BY u.id) AS src
- 注意子查询别名必须定义，且列顺序/别名要与 ON 和 UPDATE 子句中的引用一致
- 避免在子查询里写过于复杂的窗口函数或多重嵌套，影响可读性和执行计划稳定性
慎用 WHEN NOT MATCHED BY SOURCE 做级联软删
这个子句常被误用于“反向同步删除”，但它实际含义是：目标表中有、源数据中没有的记录，才触发操作。可用于模拟外键约束缺失时的清理逻辑：
- 比如定期同步客户主数据：MERGE customers_target USING customers_source ON t.id = s.id ... WHEN NOT MATCHED BY SOURCE THEN UPDATE SET is_deleted = 1, updated_at = GETDATE()
- 不能替代 DELETE 语句做硬删，除非显式写 DELETE；且务必加 WHERE 条件过滤（如仅处理 status='active' 的老数据），否则易误清
- 执行前建议先用 SELECT 验证 NOT MATCHED BY SOURCE 的记录集，确保语义符合预期
性能与安全关键提醒
MERGE 看似简洁，但隐含风险比单独 UPDATE 更高：
- ON 条件必须有高效索引支撑，否则全表扫描 + 自连接可能导致严重锁等待；尤其在大表上，优先在 target 表的 ON 字段建索引
- 不要在 MERGE 中调用 UDF（用户自定义函数），尤其是标量函数——会强制循环执行，性能断崖式下降
- 测试阶段务必开启 STATISTICS IO/ TIME，对比 MERGE 执行计划与等价 UPDATE+INSERT 的开销；某些场景下分开写反而更快更可控
- 生产环境首次运行前，用 TOP 100 加 BEGIN TRAN / ROLLBACK 模拟验证逻辑，防止误更新整表
