应优先用OPENQUERY替代四段式写法以实现条件下推；PostgreSQL宜用postgres_fdw而非dblink；MySQL应弃用FEDERATED，改用应用层分批IN查询；所有跨库方案均受网络、序列化及时区/字符集不一致制约。
用 OPENQUERY（SQL Server）代替四段式写法
SQL Server 默认的 [RemoteSrv].[db].[schema].[table] 写法，会让查询引擎把整个远程表拉到本地再 JOIN，网络带宽和内存压力都大。换成 OPENQUERY，就能把过滤、投影、甚至部分聚合下推到远程执行。
常见错误现象：SELECT * FROM local_t a JOIN [SRV01].[prod].[dbo].[orders] b ON a.uid = b.user_id 执行时发现远程 orders 表扫描行数是千万级，而实际只需要近 7 天的数据。
- 必须确保远程服务器已配好 Linked Server，且连接串里启用了
RPC Out = True -
OPENQUERY中的 SQL 是在远程实例上解析执行的，不能引用本地变量、临时表或 CTE - 如果远程语句含中文或特殊字符，注意远程库的 collation 和客户端编码一致，否则可能报
Cannot resolve collation conflict
PostgreSQL 用 postgres_fdw 而非 dblink 做高频 JOIN
dblink 每次调用都新建连接、发请求、取结果，适合一次性关联；但若每天跑几十次、每次 JOIN 百万级数据，postgres_fdw 的外部表机制更稳——它支持执行计划下推、WHERE 条件下推、JOIN 下推，甚至能走远程索引。
容易踩的坑：CREATE EXTENSION dblink 成功了，但 SELECT * FROM foreign_orders 返回空，大概率是漏了 CREATE USER MAPPING 或远程用户没被授 SELECT 权限。
- 必须先
CREATE SERVER，再CREATE USER MAPPING FOR CURRENT_USER，最后IMPORT FOREIGN SCHEMA - 远程表字段类型要和本地声明严格匹配，比如远程
id SERIAL，本地映射得写id INTEGER，不一致会导致ERROR: foreign table has too many columns - 用
EXPLAIN看执行计划：如果出现Foreign Scan on remote_table且Remote SQL里带WHERE，说明下推成功；如果只有Foreign Scan没条件，就是全量拉取
MySQL 别碰 FEDERATED，改用应用层分批 IN 查询
MySQL 8.0+ 的 FEDERATED 引擎默认禁用，启用后也不解决性能问题：它不支持 WHERE 下推，SELECT * FROM local JOIN federated_remote ON ... WHERE remote_dt = '2026-09-15' 实际仍会拉整张远程表回来再过滤。
真实生产环境里，稳定的做法是让应用控制节奏：先查主表 ID 列表，再按批次（如每 500 个）拼 IN 查远程表，最后内存合并。
- 注意
max_allowed_packet限制，超长 IN 列表会直接被 MySQL 截断，导致关联缺失 - 远程表的
user_id字段必须有索引，否则IN (…)会退化成全表扫描 - 如果远程库是只读从库，确认其
read_only=ON不影响 SELECT，但也要防备主从延迟导致查不到最新数据
所有方案都绕不开的底层瓶颈：网络与序列化开销
无论用哪种技术，只要数据要跨实例流动，就逃不开 RTT、带宽、反序列化三重损耗。一个 10MB 的结果集，在千兆内网里传输也要 80ms+，加上两端解析时间，比本地 JOIN 慢一个数量级是常态。
最容易被忽略的一点：时区和字符集不一致会导致隐式转换，让远程索引失效。比如远程库用 utf8mb4_unicode_ci，本地连接用 utf8mb4_general_ci，JOIN 字段比较时可能触发全表扫描。
- 统一两端的
time_zone设置，尤其涉及DATETIME字段 JOIN 时 - 远程表的关联字段类型必须和本地完全一致（包括是否
UNSIGNED、NOT NULL），否则优化器不敢用索引 - 如果只是偶尔查、对延迟不敏感，优先考虑定时同步宽表到本地库，用标准 JOIN —— 这往往是综合成本最低的选择
