跨数据库表连接在标准SQL中不被原生支持，必须借助各数据库的扩展机制：PostgreSQL用dblink，MySQL依赖FEDERATED引擎或应用层拼接，SQL Server需配置链接服务器；真正稳定方案是异步同步后本地JOIN。
跨数据库表连接在标准 SQL 中不被原生支持，JOIN 只能作用于同一数据库实例内的表。想“直接 JOIN 两个不同数据库的表”，本质是伪需求——必须借助数据库提供的扩展机制，否则会报错 Table not found 或 Invalid object name。
PostgreSQL 的 dblink 是最常用且轻量的方案
dblink 是 PostgreSQL 官方扩展，允许你在当前数据库中发起对另一个 PostgreSQL 实例（同库或远端）的查询，并把结果当作临时表使用。它不创建持久视图，也不依赖外部服务，适合一次性或低频跨库关联。
- 必须先在目标数据库中执行
CREATE EXTENSION dblink; - 连接串里要明确写全 host、port、dbname、user、password，例如：
'host=192.168.1.100 port=5432 dbname=prod user=reader password=xxx' -
dblink()返回的是SETOF record，必须用AS显式声明字段名和类型，否则会报column definition list is required - 示例：把本地
orders和远程prod库的customers关联
SELECT o.id, o.amount, c.name
FROM orders o
JOIN dblink('host=prod-db port=5432 dbname=prod user=ro password=123',
'SELECT id, name FROM customers')
AS c(customer_id INT, name TEXT)
ON o.customer_id = c.customer_id;注意：dblink 查询在远程执行，但 JOIN 逻辑在本地完成，大数据量时网络传输和本地内存压力明显。
MySQL 不支持 dblink，得靠 FEDERATED 引擎或应用层拼接
MySQL 原生没有跨库 JOIN 能力。FEDERATED 引擎可把远程表映射为本地表，但自 MySQL 8.0 起默认禁用且不推荐用于生产：
- 启用需在配置文件加
federated到plugin_load_add，重启服务 - 建表语句里必须指定完整远程连接信息，例如：
CONNECTION='mysql://user:pass@192.168.1.200:3306/dbname/remote_table' - 一旦远程库宕机或网络抖动，本地查询直接失败（不是返回空，是报错
ERROR 1429） - 性能不可控：每次查都走网络，无法利用本地索引，WHERE 条件下推也有限制
更稳妥的做法是：在应用层分两步查，用主键列表做二次拉取，再内存关联。比如先查出 order_ids，再 SELECT * FROM remote.customers WHERE id IN (1,2,3...)。
SQL Server 用 OPENQUERY 或四部分命名，但权限和链接服务器是关键瓶颈
SQL Server 支持两种语法，但底层都依赖「链接服务器」（Linked Server）配置：
- 四部分命名：
SELECT * FROM [remote_srv].[db_name].[schema].[table]，简单但要求链接服务器已建好且用户有权限 -
OPENQUERY：把整个查询发给远端执行，避免本地传输中间结果，例如：SELECT * FROM OPENQUERY(REMOTE_SRV, 'SELECT id,name FROM customers') - 常见错误是
Msg 7391（分布式事务不可用）或Msg 7314（对象不存在），基本都源于链接服务器未启用 RPC 或远程数据库权限不足 - 链接服务器配置本身需要
sysadmin权限，DBA 通常拒绝开放给普通开发
真正稳定可靠的跨库关联，往往绕不开物化同步
上面所有技术都是“实时查”，但线上系统真正敢用的，反而是异步同步 + 本地 JOIN：
- 用
pg_dump / pg_restore、mysqldump或 CDC 工具（如 Debezium）把远端表定期同步到本地只读库 - 同步后的表加好索引，再用标准
INNER JOIN，性能、稳定性、可观测性全部可控 - 代价是数据延迟（秒级到分钟级），但换来的是故障隔离——远端库挂了，本地查询照常
- 如果业务真要求强一致，那说明不该跨库，应该重构为单库多 schema 或微服务拆分
跨数据库 JOIN 看似一条 SQL 就能解决，实际踩坑点全在连接管理、权限控制、错误传播和性能拐点上。别迷信语法糖，先问清楚：这个“跨库”是临时调试，还是长期架构？后者几乎一定该换设计。
