PostgreSQL用UPDATE...FROM实现差异更新，必须显式判断变化行，推荐用(a,b) IS DISTINCT FROM (c,d)安全比较NULL；MySQL需用UPDATE...JOIN且顺序严格；SQL Server要求别名一致并用ISNULL()防NULL误判。
PostgreSQL 用 UPDATE ... FROM 生成差异更新脚本
直接写 UPDATE ... FROM 是最贴近“自动生成逻辑”的手动方式，但必须显式写出差异判断，不能靠工具隐式推导。关键不是语法多炫，而是 WHERE 条件里是否真正过滤了「有变化的行」。
常见错误是漏掉 NULL 安全比较：用 != 会导致 NULL != 'a' 返回 NULL，整行被跳过；正确做法是用 IS DISTINCT FROM：
UPDATE users u SET email = n.email, status = n.status, updated_at = NOW() FROM new_users n WHERE u.id = n.id AND (u.email, u.status) IS DISTINCT FROM (n.email, n.status);
-
IS DISTINCT FROM自动处理 NULL，比手写(u.email != n.email OR (u.email IS NULL) != (n.email IS NULL))简洁可靠 - 元组比较
(a,b) IS DISTINCT FROM (c,d)在 PostgreSQL 中原子生效，避免字段间逻辑错位 - 如果
new_users里存在重复id，PostgreSQL 行为未定义（可能随机选一行），务必提前去重：FROM (SELECT DISTINCT ON (id) * FROM new_users) n
MySQL 必须用 UPDATE ... JOIN，且顺序不能错
MySQL 不支持 FROM 子句，硬套 PostgreSQL 或 SQL Server 语法会直接报错 ERROR 1064。它的 JOIN 必须紧贴在 UPDATE 后、SET 前，且别名要贯穿始终。
典型翻车点：忘记加 WHERE 或 JOIN 条件松散，导致一行被多次更新（比如 t2 里一个 t1_id 对应 3 条记录，t1 那行就会被赋值 3 次，最终值取决于执行顺序）：
UPDATE users u
JOIN new_users n ON u.id = n.id
SET u.email = n.email,
u.status = n.status,
u.updated_at = NOW()
WHERE (u.email, u.status) != (n.email, n.status)
OR u.email IS NULL != n.email IS NULL
OR u.status IS NULL != n.status IS NULL;- MySQL 不支持元组级
IS DISTINCT FROM，得拆成多个OR判断，注意括号分组，否则逻辑优先级出错 -
JOIN默认是INNER JOIN，右表无匹配时左表行不会被更新——如果需求是「不存在就清空字段」，得拆成两步或改用应用层处理 - 5.7 及更早版本不支持标准
UPDATE ... JOIN语法，得用旧式UPDATE t1, t2 SET ... WHERE t1.id = t2.id，但可读性差、易误写
SQL Server 要求 UPDATE 和 FROM 中的目标表别名完全一致
SQL Server 允许 UPDATE t1 SET ... FROM t1 JOIN t2，但别名必须严格对齐：如果 UPDATE 后写的是 t1，那 FROM 里的 t1 就不能换成 src 或省略，否则报错 The table "t1" is ambiguous。
差异检测同样要防 NULL，推荐用 ISNULL() 包裹后比较，或用 EXISTS + EXCEPT 子查询（适合复杂条件）：
UPDATE u SET email = n.email, status = n.status, updated_at = GETDATE() FROM users u INNER JOIN new_users n ON u.id = n.id WHERE ISNULL(u.email, '') != ISNULL(n.email, '') OR ISNULL(u.status, '') != ISNULL(n.status, '');
-
ISNULL()比CASE WHEN简洁，但需确保替换值不和业务值冲突（比如状态字段本身可能存''） - 若字段类型含
TEXT/NTEXT（已弃用但仍见于老库），!=会报错，必须转成VARCHAR(MAX)再比 - 执行前务必用
SELECT COUNT(*)验证匹配行数，避免因 JOIN 条件错误导致零更新却以为成功
跨库/跨实例时别硬写一条 SQL
当两个表不在同一实例（比如开发库在本地，测试库在远程服务器），或者权限受限（只给 DML 不给 SELECT），强行拼一条 UPDATE ... FROM 会失败。这时候所谓“自动生成”，本质是分三步走：查差异 → 构造语句 → 执行。
DBeaver 的 Simple Structure Compare 或 mysqldiff 这类工具，底层也是先拉取元数据做比对，再拼字符串生成 ALTER TABLE；数据同步同理，只是换成了 UPDATE / INSERT 语句模板。
- 用
SELECT ... INTO OUTFILE或应用层导出带 ID 和新值的 CSV，再用脚本（Python/Shell）批量生成UPDATE users SET ... WHERE id = ?语句，可控性强 - SQL Server Data Tools 的数据比较功能会生成带事务包装的 DML 脚本，但依赖链接服务器配置，且对大表容易超时
- 真正容易被忽略的是字符集和时区：比如从日志表取
datetime更新主表，SQL Server 里GETDATE()是本地时区，而源数据可能是 UTC，不转换就直接塞进去，时间就偏了
