跨服务器JOIN失败必须先配置基础设施：SQL Server需执行sp_addlinkedserver和sp_addlinkedsrvlogin缺一不可，PostgreSQL需完成CREATE EXTENSION、CREATE SERVER、CREATE USER MAPPING及IMPORT FOREIGN SCHEMA四步，漏任一环节均因元数据缺失而报错，非语法问题。
跨服务器JOIN失败，先确认Linked Server或FDW是否真建好
没配基础设施，所有跨服务器JOIN都会直接报错，不是语法问题，是元数据根本不存在。
SQL Server必须执行两步缺一不可：sp_addlinkedserver注册别名（注意@provider = 'MSOLEDBSQL'，别用已弃用的SQLOLEDB），再用sp_addlinkedsrvlogin绑定凭据。漏掉第二步，哪怕远程开了Windows认证，也会报Login failed for user '(null)'。
PostgreSQL必须走完整流程：CREATE EXTENSION postgres_fdw（仅当前库有效）、CREATE SERVER、CREATE USER MAPPING（没这句连认证都过不去），最后IMPORT FOREIGN SCHEMA——手写CREATE FOREIGN TABLE极易字段类型映射错，比如远端jsonb被当成text。
四部分名或FDW表引用写法稍错就失败
SQL Server里必须严格用四部分名：[RemoteProd].[SalesDB].[dbo].[Customers]。少方括号、少点、少库名、大小写不一致，全算错；别指望自动补全或别名替代。
PostgreSQL中FDW表不能当本地表用：SELECT * FROM remote_customers行不通，必须先IMPORT FOREIGN SCHEMA把远端表导入本地schema，或者显式写remote_srv.customers（前提是CREATE SERVER时定义了这个别名）。
常见错误：在视图里硬写dblink('host=...', 'SELECT ...')——每次查询都新建连接，WHERE和JOIN条件无法下推，性能比全表扫描还差。
远程表是否被全量拉取，取决于能否下推过滤条件
只要JOIN或WHERE里出现本地计算逻辑（比如UPPER(t1.name) = t2.name、t1.created_at > NOW() - INTERVAL '7 days'），优化器大概率放弃下推，把整张远程表拖回来再处理。
验证方法：EXPLAIN看执行计划里是否有Remote SQL字样（PostgreSQL）或Remote Query（SQL Server）。没有？说明远程表被全量拉取。
实操建议：把能下推的条件尽量前置，比如WHERE t2.status = 'active'写在JOIN之前；避免在ON里混用函数或表达式；时间范围用闭区间而非DATE()函数。
字符集/COLLATE不一致会让跨服务器JOIN静默错配
即使两边都是utf8mb4，utf8mb4_unicode_ci和utf8mb4_0900_as_cs也不能直接等值比较——MySQL会报Illegal mix of collations，PostgreSQL可能返回空结果但不报错。
查真实排序规则：SELECT COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'remote_db' AND TABLE_NAME = 't2' AND COLUMN_NAME = 'code'，别信库级默认值。
临时救急：在JOIN条件里显式对齐，如ON t1.code COLLATE utf8mb4_0900_as_cs = t2.code COLLATE utf8mb4_0900_as_cs；但长期要改表：ALTER TABLE t2 MODIFY code VARCHAR(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs。
容易被忽略的是连接层污染：@@collation_connection若为utf8mb4_general_ci，而字段是utf8mb4_0900_as_cs，字面量（如'abc'）一进来就失真——JDBC得加&collationConnection=utf8mb4_0900_as_cs，Python pymysql传charset='utf8mb4'还不够，得额外指定collation参数。
