mysql跨库update一定报错，因硬性禁止跨schema引用表，即使同实例写update db1.t1 join db2.t2也会触发error 1109；唯一合法绕过方式是用临时表映射，但仅适用于小数据量非实时场景。
不能用一条 SQL 同时更新两个不同数据库（跨库）的表，这是 MySQL、PostgreSQL、SQL Server 等主流数据库的硬性限制，不是语法写错或权限问题。
MySQL 跨库 UPDATE 为什么一定报错？
MySQL 明确禁止在 UPDATE 语句中跨 schema 引用表。哪怕两个库在同一实例，写 UPDATE db1.t1 JOIN db2.t2 也会触发 ERROR 1109 (42S02): Unknown table 'db2.t2' in MULTI UPDATE。
- 临时表是唯一“合法”绕过方式：先
CREATE TEMPORARY TABLE tmp AS SELECT * FROM db2.t2，再UPDATE db1.t1 JOIN tmp——但只适合小数据量、非实时场景 - 视图无效：
CREATE VIEW v AS SELECT * FROM db2.t2后再UPDATE v，MySQL 仍拒绝，因为底层跨库 - 别指望 binlog 同步能替代 UPDATE：它解决的是最终一致性，不是原子性同步；且
binlog_format必须为ROW，否则解析失败
PostgreSQL 跨库更新要靠 postgres_fdw
PostgreSQL 原生支持跨库（甚至跨实例）查询，但前提是启用 postgres_fdw 扩展并创建 foreign server + foreign table。
- 没配
postgres_fdw时，UPDATE t1 SET x = t2.y FROM other_db.public.t2直接报错syntax error at or near "FROM" - 配好后，
FROM子句可引用远端表，但性能受网络延迟和远端查询效率制约，务必加WHERE条件下推 - 远端表若无主键或索引，本地
UPDATE可能触发全量拉取，内存爆掉或超时
SQL Server 跨库 UPDATE 是允许的，但有陷阱
SQL Server 允许直接写 UPDATE db1.dbo.t1 SET col = db2.dbo.t2.val FROM db2.dbo.t2 WHERE t1.id = t2.id，语法合法，但实际执行风险高。
- 事务锁范围扩大：一次 UPDATE 可能同时锁住两个库的表，阻塞其他业务
- 网络抖动导致语句失败时，部分行已更新、部分未更新，状态不一致
- 如果目标库是只读副本（如 Always On Secondary），语句直接失败，不会自动降级
- 更稳妥的做法是用
SELECT INTO或INSERT INTO ... SELECT先把源数据拉到本地临时表，再更新——可控、可重试、锁粒度小
真正靠谱的跨库同步从来不在单条 SQL 里
所谓“高效”，不是指写得短，而是指可重试、低干扰、可观测。生产环境没人真用跨库 UPDATE 做核心数据同步。要么用 CDC 工具（Debezium/canal + Kafka + Flink），要么应用层双写+幂等校验，要么定期用 mysqldump --where / pg_dump -t 导出再导入。那些声称“一条 SQL 解决跨库同步”的方案，基本都隐含了单实例、同版本、弱一致性容忍等前提——而这些前提，恰恰是线上系统最不敢假设的。
