MySQL跨库UPDATE不支持直接JOIN，因语法硬限制报错1109；可行方案包括临时表映射、binlog同步（需ROW格式+Kafka重试）、应用层双写+校验，但Seata/ShardingSphere跨实例事务不可靠。
MySQL 跨库 UPDATE 为什么不能直接用 JOIN？
因为 MySQL 的多表 UPDATE 语法不支持跨数据库（不同 schema）的 JOIN，哪怕两个库在同一台服务器上。UPDATE db1.table1 JOIN db2.table2 看似合理，实际会报错 ERROR 1109 (42S02): Unknown table 'db2.table2' in MULTI UPDATE —— 这是 MySQL 的硬限制，不是权限或配置问题。
- 唯一能绕过的方式是把目标库表“映射”成本地临时表（如用
CREATE TEMPORARY TABLE ... SELECT），但只适用于小数据量、非实时场景 - 如果用视图（
CREATE VIEW）跨库引用，UPDATE 依然失败：视图底层表跨库时，MySQL 不允许通过视图更新 - 注意：PostgreSQL 没这个限制，
UPDATE ... FROM other_db.schema.table是合法的，但前提是启用了postgres_fdw
用 binlog + 解析工具做最终一致性同步，靠谱吗？
靠谱，但“最终一致”这四个字意味着你得接受几秒到几分钟的数据延迟，且必须自己处理冲突和幂等。
- 典型组合是：
canal（阿里开源）或debezium订阅源库 binlog，解析出INSERT/UPDATE/DELETE事件，再投递到目标库 - 关键坑：binlog 格式必须为
ROW（binlog_format=ROW），STATEMENT或MIXED会导致解析失败或数据错乱 - 目标库写入失败时，消息不能丢——得用带 ACK 的队列（如
Kafka），并实现重试+死信隔离；否则一次网络抖动就可能丢变更 - 主键变更（比如
UPDATE SET id = ?）极难处理，绝大多数同步工具直接跳过或报错，得提前约定禁止这类操作
Seata 和 ShardingSphere 的分布式事务，真能跨 MySQL 实例生效？
不能。它们的 AT 模式（自动补偿）只在单个数据库实例内有效，跨物理实例时，全局事务协调器（TC）无法保证所有分支的原子提交。
-
Seata的AT模式依赖本地 undo_log 表回滚，但跨实例后，各库的 undo_log 互不可见，TC 无法构造反向 SQL -
ShardingSphere-Proxy的XAShim模式需要底层数据库支持 XA 协议（MySQL 5.7+ 支持，但性能差、锁粒度大），且要求所有参与库在同一个集群或至少能互相建立 XA 连接——生产环境跨机房基本不可行 - 如果你看到“Seata 跨库事务成功”的案例，大概率是测试时把多个库部署在同一 MySQL 实例下（不同 schema），这本质上仍是单点事务
最轻量又可控的方案：应用层双写 + 状态校验
适合中小规模、对强一致性无硬性要求（比如报表库、搜索库、缓存库），胜在逻辑透明、调试简单、不引入新组件。
- 核心动作只有三步：
BEGIN→ 写主库 → 写副库 →COMMIT；任一失败就ROLLBACK并告警 - 必须加幂等控制：副库写入前查一下
WHERE updated_at 或用 <code>INSERT ... ON DUPLICATE KEY UPDATE避免重复 - 异步补救比强同步更实用：主库写完立刻返回用户，再用定时任务扫描主库最近 5 分钟的变更，对比副库缺失项并修复——这样既保响应速度，又兜底数据完整性
- 别省略监控：对双写失败率、副库延迟时间、校验不一致条数打点，否则问题会悄无声息堆积数周
跨数据库同步没有银弹。真正麻烦的从来不是技术选型，而是怎么定义“同步完成”——是写入成功？还是下游可查？或是业务逻辑可执行？这个边界一旦模糊，所有方案都会在某个凌晨三点开始报错。
