MySQL/PostgreSQL 不支持跨库 UPDATE 是因事务和锁机制无法跨数据库实例边界协调；必须通过本地临时表分步同步，确保可控、可验、可中断。
不能直接跨库 UPDATE，必须用中间表中转；否则会报错或静默失败。
为什么 MySQL/PostgreSQL 不支持跨库 UPDATE 语句
MySQL 报错典型是 ERROR 1105 (HY000): Unknown error 或字段解析失败；PostgreSQL 直接拒绝解析跨库名，如写 UPDATE db2.users SET name = u1.name FROM db1.users u1 WHERE ... 会触发 ERROR: cross-database references are not implemented。这不是权限问题，是内核设计限制——事务和锁机制无法跨数据库实例边界协调。
常见错误做法包括：在 SQL 中硬写 db_name.table_name 期望 JOIN 生效、用视图伪装跨库、或误以为链接服务器（如 MySQL FEDERATED）能用于 UPDATE（它只读）。这些都会在执行时中断或产生不可控副作用。
- MySQL 的
FEDERATED引擎不支持 DML 写入，仅限 SELECT - PostgreSQL 的
postgres_fdw虽支持 INSERT/UPDATE，但需额外配置用户映射、远程事务隔离，并且性能开销大、失败后难回滚 - SQL Server 的
OPENQUERY在 UPDATE 中受限严重，多数场景下返回Ad hoc updates to system catalogs are not allowed
安全方案：用本地临时表 + 分步同步
核心逻辑是把目标库数据“拉”到当前库做中间计算，再把结果“推”回去。全程可控、可验、可中断。
以 MySQL 为例，假设要将 backup_db.user_profiles 中的 status 同步到 main_db.users：
- 第一步：建本地临时表存目标数据快照
CREATE TEMPORARY TABLE tmp_sync AS SELECT id, status FROM backup_db.user_profiles WHERE updated_at > '2026-10-01'; - 第二步：用 JOIN 验证匹配范围
SELECT COUNT(*) FROM main_db.users u JOIN tmp_sync t ON u.id = t.id WHERE u.status != t.status;—— 看有多少真需要改 - 第三步：执行更新（带事务 + 行数校验）
BEGIN; UPDATE main_db.users u JOIN tmp_sync t ON u.id = t.id SET u.status = t.status; SELECT ROW_COUNT(); COMMIT; - 第四步：清空临时表（自动销毁，但显式
DROP TEMPORARY TABLE tmp_sync;更清晰）
PostgreSQL 类似，但要用 CREATE TEMP TABLE，且注意 UPDATE ... FROM 语法：UPDATE main_db.users SET status = t.status FROM tmp_sync t WHERE users.id = t.id;
WHERE 条件失效、索引没走？检查这三点
跨库同步最常卡在性能上，不是语法错，而是慢到像卡死——本质是没走索引或隐式类型转换。
-
id字段在两个库中类型必须一致：比如都是BIGINT UNSIGNED，若一边是INT一边是BIGINT，JOIN 时会触发隐式转换，导致索引失效 - 临时表默认无索引，
JOIN前务必加：ALTER TABLE tmp_sync ADD INDEX idx_id (id);（MySQL）或CREATE INDEX ON tmp_sync(id);（PG） - WHERE 中避免函数包裹字段，例如
WHERE DATE(created_at) = '2026-10-01'→ 改成WHERE created_at >= '2026-10-01' AND created_at
生产环境必须加的兜底动作
临时表只是中转，不是保险丝。真正防翻车的是这几步：
- 所有操作前，对目标表做
SELECT快照备份（哪怕只取 100 行）：SELECT * FROM main_db.users WHERE id IN (SELECT id FROM tmp_sync LIMIT 100) INTO OUTFILE '/tmp/pre_update_snapshot.csv'; - 更新后立刻查影响行数：
SELECT ROW_COUNT()（MySQL）或GET DIAGNOSTICS rowcount = ROW_COUNT;（PG），不等于预期值就别继续 - 主从延迟敏感场景，更新后加
SLEEP(0.05)（MySQL）或pg_sleep(0.02)（PG），防止从库堆积 - 禁止在凌晨低峰期以外跑；如果单次同步超 5 万行，必须拆成
WHERE id BETWEEN x AND y分片，而不是依赖 LIMIT
临时表本身不持久，但中间状态一旦出错，修复成本比直接跨库 UPDATE 更高——因为你要重拉快照、重算差异、重校验一致性。所以每一步的输出都要留痕，别省那几行 SELECT。
