postgresql用update...from语法，目标表仅写在update后，from后跟单个源（可为join子查询），where必须含显式关联条件；sql server用update t1 set...from t1 join t2 on...，目标表别名须在update和from中一致，且join类型需显式声明。
UPDATE ... FROM 在 PostgreSQL 和 SQL Server 中怎么写？
直接用 UPDATE 关联另一个表更新，是主流数据库最常用的同步方式。但语法差异大，写错就会报错或误更新。
- PostgreSQL 必须用
UPDATE ... FROM语法，SET后不能直接跟子查询（除非用EXISTS），否则会提示column reference "xxx" is ambiguous - SQL Server 支持
UPDATE t1 SET ... FROM t1 JOIN t2 ...，但必须显式指定别名，且UPDATE后的表名要和FROM中的别名一致，否则报错The table "<code>t1" is ambiguous - MySQL 不支持
UPDATE ... FROM，得用UPDATE ... JOIN，且JOIN必须写在UPDATE表名之后，顺序错就语法错误
示例（PostgreSQL）：
UPDATE orders o SET status = n.status, updated_at = NOW() FROM new_orders n WHERE o.order_id = n.order_id AND (o.status IS DISTINCT FROM n.status);注意这里用
IS DISTINCT FROM 而不是 !=，能正确处理 NULL 比较。
如何只更新真正变化的字段，避免无意义的 UPDATE？
不加判断地全量更新，会触发所有行的 updated_at、产生冗余 WAL 日志、激活触发器、甚至引发主从延迟。关键在「差异检测」。
- 用
IS DISTINCT FROM（PostgreSQL）或IS NULL+!=组合（MySQL/SQL Server）来安全比较含NULL的字段 - 多个字段需同时变化才更新？用括号包裹条件：
(t1.a, t1.b) IS DISTINCT FROM (t2.a, t2.b)（PostgreSQL 支持元组比较） - 避免写成
t1.a != t2.a OR t1.b != t2.b—— 如果任一字段为NULL，整个表达式结果为NULL，导致条件失效
MySQL 中用 JOIN 更新时为什么总少更新几行？
常见原因是 JOIN 类型隐式变成 INNER JOIN，而你本意想更新左表所有匹配行，但漏掉了右表缺失的情况。
- MySQL 的
UPDATE t1 JOIN t2默认是内连接，右表没匹配的行不会出现在结果中 —— 所以那些需要设为默认值或清空的记录根本不会被触达 - 如果要覆盖「存在即更新，不存在即置空」，得用
LEFT JOIN，但 MySQL 不允许在UPDATE里直接写LEFT JOIN；得改用子查询或分两步：先UPDATE ... WHERE id IN (SELECT ...)，再UPDATE ... WHERE id NOT IN (SELECT ...) - 更稳妥的做法是：先用
SELECT验证匹配行数，再执行UPDATE，比如SELECT COUNT(*) FROM target t LEFT JOIN source s ON t.id = s.id WHERE s.id IS NULL
UPDATE 同步时锁表范围和性能怎么控制？
一次更新百万行，很容易锁表太久、阻塞业务。不能只靠加 LIMIT（MySQL 支持，PostgreSQL 不支持直接 LIMIT），得从策略入手。
- PostgreSQL 没有
UPDATE ... LIMIT，但可以用WHERE ctid IN (SELECT ctid FROM ... LIMIT 1000)分批，注意ctid不稳定，仅适合单次脚本运行 - 更通用的做法：按主键范围分片，比如
WHERE id BETWEEN 10000 AND 20000，配合索引确保高效定位 - 务必在
JOIN条件和WHERE差异判断字段上建联合索引，否则每次扫描都是全表 - 执行前先
EXPLAIN ANALYZE看执行计划，确认走了索引；特别留意是否出现Hash Join或Seq Scan—— 这往往是性能瓶颈源头
实际生产中，字段级差异同步看似简单，但 NULL 处理、锁粒度、分批边界、索引缺失这四点，任一没踩准都会让语句从“秒级完成”变成“卡住半小时还滚不回”。动手前先查执行计划，比多试三次更重要。
