SQL Server原生支持跨库JOIN，需用四部分命名法（服务器.数据库.架构.表），本地可省略服务器名；MySQL仅支持同实例跨库前缀写法；PostgreSQL须依赖dblink或postgres_fdw扩展。
SQL Server里用四部分命名法跨库JOIN
SQL Server原生支持跨数据库关联，不需要额外配置，只要权限和对象存在即可。关键在于用「服务器.数据库.架构.表」的完全限定名写法，比如 [AdventureWorks].[Sales].[SalesOrderHeader]。
常见错误是只写两段或三段名，比如 Sales.SalesOrderHeader（缺数据库）或 AdventureWorks.SalesOrderHeader（缺架构），执行时直接报 Invalid object name。
- 本地实例可省略服务器名，写成
[DB1].[dbo].[TableA]JOIN[DB2].[dbo].[TableB] - 跨实例必须显式指定服务器名，如
[SRV01].[DB1].[dbo].[T1]，且该服务器需在本地已注册为Linked Server（否则报错Could not find server） - 所有数据库名、架构名、表名建议用方括号包裹，避免遇到带空格或关键字的名称时报错
MySQL不支持跨库JOIN的语法糖，但能用库名前缀实现
MySQL没有“四部分名”概念，但允许在表名前直接加数据库名作为前缀，形如 db1.table1 JOIN db2.table2。这本质仍是单实例内的逻辑隔离，不是真正的跨实例。
典型翻车点：误以为能用 host.db.table 写法——MySQL不认这个，会当成非法标识符报 Unknown database 'host'。
- 必须确保当前登录用户对两个数据库都有 SELECT 权限，否则报
SELECT command denied to user - 不能用反引号把整个
db.table包起来，只能分别包：`db1`.`table1`JOIN`db2`.`table2` - 如果两个库在不同物理服务器上，MySQL原生不支持直接JOIN，得用FEDERATED引擎（已弃用）或应用层拼接，别硬刚
PostgreSQL需要dblink或postgres_fdw扩展才能跨库
PostgreSQL默认禁止跨数据库查询，因为每个数据库是独立的PID空间和事务边界。想JOIN，必须借助扩展——dblink（轻量，函数调用风格）或 postgres_fdw（重量，可建外部表）。
新手常卡在第一步：连 CREATE EXTENSION dblink 都报错，原因是没在目标数据库里执行，或者用户没 CREATEROLE 权限。
- 用
dblink时，JOIN要拆成子查询 + 函数调用，例如：SELECT * FROM local_t a JOIN (SELECT * FROM dblink('host=...','SELECT id,name FROM remote_t') AS t(id int, name text)) b ON a.id = b.id -
postgres_fdw更接近“真实表”，但需先CREATE SERVER、CREATE USER MAPPING、IMPORT FOREIGN SCHEMA，漏一步就查不到数据 - 跨库JOIN在PG里本质是远程查询，网络延迟、结果集大小、WHERE下推能力都会显著影响性能，别在大表上直接
SELECT *
跨实例JOIN的本质是网络I/O，不是SQL语法问题
无论哪种数据库，只要涉及不同物理服务器，所谓的“跨库JOIN”最终都变成客户端或服务端发起的一次远程查询请求。语法只是表象，背后是连接建立、认证、序列化、网络传输、结果合并这一整套开销。
最容易被忽略的是锁和事务行为：SQL Server Linked Server 默认开启 RPC，远程操作可能持有远端锁；PG的 dblink 不参与本地事务，出错不会回滚远端操作；MySQL更干脆——根本不让跨实例JOIN，逼你处理一致性。
- 生产环境优先考虑ETL同步或应用层组装，而不是实时跨实例JOIN
- 测试时用
EXPLAIN或执行计划看清楚：JOIN条件有没有下推？数据是在远端过滤后传回来，还是全量拉取再本地计算？ - 如果必须用，记得设好超时（如SQL Server的
sp_serveroption 'connect timeout'），否则一个慢查询会拖垮整个批处理
