子查询跨库仅适用于单次拉取、临时校验或中间视图，不可用于持续同步；必须用完全限定名（如db1.table1），且权限需覆盖源库select与目标库insert/update。
SELECT 语句里用子查询做跨库同步，不是标准的数据同步方案，它只能「单次拉取」，不能持续、带状态、防冲突。真要同步数据，得靠 ETL 工具、binlog 或数据库原生的复制机制。但如果你只是临时补一条记录、校验一致性、或构建中间视图，用带完全限定名的子查询是可行的——前提是权限和语法都对得上。
跨数据库子查询必须用完全限定名
不同数据库对跨库引用的语法差异很大，MySQL、PostgreSQL、SQL Server 都支持 database.schema.table 形式，但 PostgreSQL 要求 schema 显式写出（通常是 public），而 MySQL 默认 schema 就是 database 名，所以常写成 db1.table1。漏掉任意一级，就会报错：Unknown database 'xxx' 或 relation "xxx" does not exist。
- SQL Server：支持
[db_name].[schema].[table]，方括号可选，但含特殊字符时必须加 - MySQL：支持
db_name.table_name，不支持 schema 层级（除非启用了 ANSI 模式） - PostgreSQL：必须写全
db_name.public.table_name—— 注意：数据库名不能在表引用中直接出现，真正生效的是search_path+schema.table；跨库需用dblink或外部表（foreign table） - 权限必须同时覆盖两个库：用户得有
SELECT权限在源库表，也要有目标库的INSERT/UPDATE权限（如果用于同步写入）
子查询嵌套在 INSERT/UPDATE 中的典型写法
常见需求是“把库 A 的最新订单状态，批量更新到库 B 的客户表”。这时不能只写 SELECT，得配合 INSERT ... SELECT 或 UPDATE ... FROM（后者非标准 SQL，MySQL 不支持，PostgreSQL 和 SQL Server 支持）。
- MySQL 只能走
INSERT INTO db2.customers (...) SELECT ... FROM db1.orders WHERE ... - SQL Server 可用
UPDATE db2.customers SET status = o.status FROM db2.customers c INNER JOIN db1.orders o ON c.order_id = o.id - PostgreSQL 要么用
UPDATE ... FROM（同 SQL Server），要么用子查询：UPDATE db2.customers SET status = (SELECT status FROM db1.orders o WHERE o.id = customers.order_id) WHERE order_id IN (SELECT id FROM db1.orders)—— 注意这里子查询必须返回至多一行，否则报错more than one row returned by a subquery used as an expression
嵌套子查询 + 完全限定名容易踩的坑
你以为写对了表名就万事大吉？实际执行时还卡在几个隐蔽位置：
-
ORDER BY和LIMIT在子查询里无效（MySQL 5.7+ 允许，但低版本会报错This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'） - 子查询里用了聚合但没
GROUP BY，外层又没限制行数，可能触发Subquery returns more than 1 row - 跨库字段类型不一致：比如
db1.users.id是BIGINT，db2.logs.user_id是INT，插入时会静默截断或报错，取决于 SQL mode - 事务隔离问题：子查询读取的是快照，而外层写入是当前事务，若中间有并发修改，结果可能不一致 —— 这不是语法问题，但线上出 bug 时很难归因
为什么别依赖子查询做“同步”逻辑
子查询本质是**一次性表达式求值**，它没有重试、断点续传、冲突检测、幂等保障。哪怕你写了个看似完整的 INSERT ... SELECT ... WHERE NOT EXISTS，只要源表有新数据插入、目标表被手动改过、或网络抖动导致部分执行，下次再跑就可能重复插入或漏数据。
- 真正同步要靠带位点（binlog position / LSN）的工具，比如
mysqldump+mysqlbinlog、Debezium、pglogical - 如果只是开发环境临时对齐，建议用导出 CSV +
LOAD DATA，比嵌套子查询更可控、更易验证 - 任何带
UPDATE或DELETE的跨库子查询，上线前务必在测试库用EXPLAIN看执行计划 —— 很多时候它会放弃索引，全表扫描源库
