MySQL的UPDATE JOIN只能更新一个表，即UPDATE后的目标表，关联表仅用于取值且不可修改。
MySQL里UPDATE JOIN只能改一个表，别想同时更新两张
MySQL的UPDATE ... JOIN语法本质是“单表更新 + 多表关联取值”，不是真正意义上的多表同步。你写UPDATE t1 JOIN t2 ON ... SET t1.col = t2.col，只有t1被修改，t2完全不动——哪怕你在SET里写了t2.x = ...，也会报错ERROR 1064（MySQL 8.0+已禁用多表SET）。
常见错误现象：执行后发现t2字段没变，或者直接报语法错误；有人误以为加个JOIN就能双向写，结果只改了一半。
- 必须把目标表（要改的那张）放在
UPDATE关键字后面，且不能加别名（如UPDATE users u是错的，得写UPDATE users） - 关联表可以加别名，但
SET里所有字段必须带目标表别名前缀，比如users.status，不能只写status - 如果关联表有重复匹配行（比如
t2对同一个t1.id有多条记录），MySQL会随机选一条更新，结果不可控
PostgreSQL和SQL Server用FROM或子查询，逻辑更清晰但写法不同
PostgreSQL不支持UPDATE ... JOIN，得用UPDATE ... FROM；SQL Server用UPDATE ... FROM ... JOIN，两者都只更新UPDATE后面的那张表，FROM或JOIN后的表纯属只读数据源。
容易踩的坑：PostgreSQL里如果FROM子句里重复出现目标表名（比如UPDATE users FROM users u JOIN ...），会报错table name "users" specified more than once；SQL Server里如果SET列没加别名前缀，会报Msg 107。
- PostgreSQL示例：
UPDATE users SET email = tmp.email FROM temp_updates tmp WHERE users.id = tmp.user_id—— 注意tmp不能出现在SET左边 - SQL Server示例：
UPDATE t SET t.status = s.new_status FROM orders t INNER JOIN status_updates s ON t.id = s.order_id——t是必须的别名，且SET里所有列都要带t. - 两者都要求
WHERE或ON条件能一对一匹配，否则可能产生笛卡尔积或静默覆盖
SQLite只能靠子查询，性能差但兼容性好
SQLite完全不支持JOIN或FROM在UPDATE中，唯一办法是用相关子查询：UPDATE t1 SET col = (SELECT col FROM t2 WHERE t2.id = t1.id)。它简单、跨平台，但每行都会触发一次子查询，大表更新极慢。
典型错误：子查询返回多行时，SQLite直接报错subquery returns more than one row；如果t2.id不是唯一键，就得提前聚合或加LIMIT 1。
- 安全写法：
UPDATE users SET score = (SELECT points FROM user_logs WHERE user_logs.user_id = users.id AND status = 'done' ORDER BY updated_at DESC LIMIT 1) - 必须配
WHERE EXISTS避免NULL覆盖：WHERE EXISTS (SELECT 1 FROM user_logs WHERE user_logs.user_id = users.id AND status = 'done') - 没有索引时，
user_logs.user_id字段全表扫描次数 =users总行数，百万级表慎用
跨库或跨实例时JOIN彻底失效，别硬试
MySQL允许SELECT db1.t1 JOIN db2.t2，但UPDATE db1.t1 JOIN db2.t2会直接报错ERROR 1103；PostgreSQL和SQL Server也不支持跨库UPDATE FROM或JOIN。这时候所谓“同步”其实是ETL流程，不是一条SQL能解决的。
错误尝试：UPDATE prod.users u JOIN backup.users b ON u.id = b.id SET u.status = b.status —— 不管引擎版本多新，都会失败。
- 可行方案一：用
mysqldump --where导出变更数据，再生成INSERT ... ON DUPLICATE KEY UPDATE语句批量回写 - 可行方案二：应用层双写——更新
b表后，立刻查出变更ID列表，再发请求更新a表对应行 - 任何跨实例操作都必须考虑网络延迟、事务隔离和幂等性，数据库层JOIN在这里只是幻觉
SELECT先查一遍匹配结果集，数清楚行数，再动手UPDATE。 
