必须先配置连接基础设施，否则所有跨服务器join都会直接失败：sql server需建linked server（sp_addlinkedserver与sp_addlinkedsrvlogin缺一不可），postgresql需配postgres_fdw（含create extension、create server、user mapping及import foreign schema），无语法糖可绕过。
必须先配置连接基础设施，否则所有跨服务器 JOIN 都会直接失败——SQL Server 要建 Linked Server，PostgreSQL 要配 postgres_fdw，没有语法糖能绕过这步。
SQL Server 中用四部分名写 JOIN 前，sp_addlinkedserver 和 sp_addlinkedsrvlogin 缺一不可
你不能在 FROM 或 JOIN 里直接写 [SRV02].[DB1].[dbo].[Orders] 就跑通。SQL Server 会立刻报错：Could not find server 'SRV02' in sys.servers。这不是权限问题，是元数据根本不存在。
- 先执行
sp_addlinkedserver注册别名（如'RemoteProd'），指定@provider = 'MSOLEDBSQL'（别用已弃用的SQLOLEDB或MSDASQL）和@datasrc = '192.168.5.100\INST1' - 再执行
sp_addlinkedsrvlogin 'RemoteProd', 'false', NULL, 'sql_user', 'pwd456'——漏掉这句，哪怕远程开 Windows 认证，也会报Login failed for user '(null)' - JOIN 写法必须带全四部分：
SELECT * FROM local_t a JOIN [RemoteProd].[SalesDB].[dbo].[Customers] b ON a.cid = b.id；少方括号、少点、少库名，都算错
PostgreSQL 用 postgres_fdw 实现跨服务器 JOIN，不能跳过 IMPORT FOREIGN SCHEMA
直接在视图里写 dblink('host=...','SELECT ...') 是反模式：每次查询都新建连接，无法下推 WHERE、JOIN 条件，性能崩得比全表扫描还快。
- 先在本地库运行
CREATE EXTENSION postgres_fdw（不是全局，是当前数据库） - 再
CREATE SERVER remote_srv FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '192.168.5.101', port '5432', dbname 'prod') - 必须
CREATE USER MAPPING FOR CURRENT_USER SERVER remote_srv OPTIONS (user 'fdw_user', password 'secret')，否则连认证都过不去 - 关键一步：
IMPORT FOREIGN SCHEMA public FROM SERVER remote_srv INTO local_schema——手写CREATE FOREIGN TABLE容易字段类型映射错（比如远端jsonb被当成text）
跨服务器 JOIN 的性能陷阱：远程表是否被全量拉取，取决于能否下推过滤条件
不管 SQL Server 还是 PostgreSQL，只要查询里出现本地计算逻辑，优化器大概率放弃下推，把整张远程表拖回来再处理。
- SQL Server 中，
WHERE UPPER(remote_name) = 'ABC'或ORDER BY remote_date DESC会让远程端返回全部数据，本地再过滤排序 - PostgreSQL 中，
WHERE now() - remote_ts 同样阻断下推；应改用远端已有的函数，或提前算好时间戳传过去 - 查
EXPLAIN输出：SQL Server 看执行计划里有没有 “Remote Query” 节点；PostgreSQL 看有没有Foreign Scan on ft_name且没被Materialize包裹 - 远程表没主键或唯一索引，
postgres_fdw默认不敢下推 JOIN 条件——加ALTER FOREIGN TABLE ft_name OPTIONS (SET updatable 'true')也无用，得先补索引
真正难的从来不是建链接，而是让 JOIN 不拉全量数据。网络延迟可以优化，但设计上没预留下推能力，后续只能靠应用层拆查+内存合并硬扛。
