MERGE 默认覆盖整行是因为它仅依据ON条件匹配后执行SET子句中所有列，不自动跳过未变更值；需用CASE配合NULL安全比较实现按需更新，或借助触发器/CDC等机制精准捕获真实变更。
SQL MERGE 为什么默认会覆盖整行而不是只更新变动列
MERGE 本身不区分“哪些列值变了”，它只按 ON 条件匹配，然后执行 WHEN MATCHED THEN UPDATE SET ... 中列出的所有列——无论右边源数据的值是否和目标表当前值一致。数据库不会自动做“值比较再跳过”，这是设计使然，不是 bug。
所以“仅更新发生变动的列”不是 MERGE 的内置能力，而是需要你显式写逻辑来实现。
用 CASE 表达式在 UPDATE 子句中做逐列值比对
核心思路：对每个要更新的列，用 CASE WHEN target.col != source.col THEN source.col ELSE target.col END 包裹，确保只有值不同时才写入新值。
- 必须显式写出所有目标列名，不能用
* -
source.col指的是USING子句中别名（如s）引用的字段；target.col是目标表别名（如t）引用的字段 - 注意 NULL 安全比较：直接用
!=会漏掉 NULL ↔ 非 NULL 变更，建议用NOT (t.col IS NOT DISTINCT FROM s.col)（PostgreSQL/SQL Server）或ISNULL(t.col, '') != ISNULL(s.col, '')（SQL Server）等适配写法
MERGE INTO users t
USING staging_users s ON t.id = s.id
WHEN MATCHED THEN
UPDATE SET
name = CASE WHEN t.name IS NOT DISTINCT FROM s.name THEN t.name ELSE s.name END,
email = CASE WHEN t.email IS NOT DISTINCT FROM s.email THEN t.email ELSE s.email END,
status = CASE WHEN t.status IS NOT DISTINCT FROM s.status THEN t.status ELSE s.status END;
UPDATE 触发器或 CDC 日志更适合“真变动检测”场景
如果业务要求严格记录“实际变更行为”（比如审计、下游同步），靠 MERGE + CASE 在语句层模拟容易出错：比如触发器里又改了某列、计算列依赖变更列、并发下两次读到不同中间态。
- SQL Server 可用
COLUMNS_UPDATED()或变更数据捕获（CDC） - PostgreSQL 推荐用
pg_logical插件或监听UPDATE事件并比对OLD/NEW - MySQL 8.0+ 可配合
BINLOG_ROW_IMAGE = FULL和解析 binlog 实现
这些机制在事务提交后才确认“到底哪些列被改了”，比 MERGE 预判更可靠。
性能与可维护性权衡：别为了“少写几个字”牺牲清晰度
有人试图用动态 SQL 拼接只含变动列的 UPDATE，但代价很高：每次都要查目标行、构造语句、执行计划无法复用、难以调试。
- 简单业务表（
- 列多且变更稀疏时，先用
WHERE过滤掉完全无差异的行（如WHERE NOT (t.name IS NOT DISTINCT FROM s.name AND t.email IS NOT DISTINCT FROM s.email)），再进 MERGE，能减少锁和日志量 - 应用层做变更检测（如 Java 对比 DTO）再调用精简版 UPDATE，有时比在 SQL 层硬扛更可控
真正难的不是语法怎么写，而是想清楚“谁负责定义‘变动’”——是数据库？应用？还是某个中间服务？这个边界没划清，后面所有优化都可能白忙。
