MySQL 8.0+ 不能直接 JOIN 另一实例的表，原生 JOIN 仅支持同实例库表；跨实例需用 FEDERATED 引擎（需手动启用并严格匹配结构）或外部代理，但非原生支持。
MySQL 8.0+ 能不能直接 JOIN 另一个 MySQL 实例的表？
不能。原生 SELECT * FROM db1.table1 JOIN db2.table2 只支持同实例下的库表，db2 如果是另一个 MySQL 实例（哪怕在同一台机器、不同端口），会报错 Unknown database 'db2' 或连接拒绝——因为解析器根本没走网络层，只查本地实例的元数据。
真正能跨实例关联的，只有两类方案：联邦引擎（FEDERATED）或外部服务代理（如 ProxySQL、TiDB 的外部表），但后者不属于 MySQL 原生能力。
-
FEDERATED引擎必须在目标实例开启远程访问（bind-address不能是127.0.0.1），且源实例需显式创建映射表 - MySQL 5.7 默认禁用
FEDERATED，8.0 默认不编译该引擎，需启动时加--federated参数并确认SHOW ENGINES中状态为YES - 映射表的 DDL 必须和远端表结构严格一致（包括字符集、排序规则、字段顺序），否则
INSERT/UPDATE可能静默失败
PostgreSQL 的 postgres_fdw 怎么配才不卡死查询？
配完 CREATE SERVER 和 CREATE USER MAPPING 后，常见问题是 SELECT 响应极慢，甚至超时。这不是网络延迟导致的，而是 PostgreSQL 默认把远程表当“黑盒”，不做下推优化——比如 WHERE id = 123 会拉回整张远端表再过滤。
关键在 IMPORT FOREIGN SCHEMA 后手动启用下推：
- 建好
FOREIGN TABLE后，执行ALTER FOREIGN TABLE ft_name OPTIONS (SET updatable 'true')（如果远端支持写） - 确保远端表有主键或唯一索引，否则
postgres_fdw不敢下推JOIN条件和LIMIT - 避免在
WHERE中用本地函数包裹远端字段，例如WHERE upper(remote_col) = 'ABC'会强制拉全量——改用远端已有的函数或提前计算
小提示：EXPLAIN 输出里看到 Foreign Scan on ft_name 是正常的，但如果出现 Materialize 包裹它，说明有中间缓存，大概率是下推被阻断了。
SQL Server 链接服务器 sp_addlinkedserver 连 MySQL 报错 OLE DB provider 'MSDASQL' reported an error
这错误本质是 ODBC 层失败，不是 SQL Server 本身问题。Windows 上最稳的路径是：用 64 位 ODBC 数据源管理器配好 MySQL ODBC Connector（推荐 8.0 Unicode 版），再在 SQL Server 里引用这个 DSN 名称。
- 别用
Microsoft OLE DB Provider for ODBC Drivers（MSDASQL），它在 Win10/Win11 上兼容性差；换成MySQL ODBC 8.0 Unicode Driver对应的 provider 名（查sys.servers的provider列） -
sp_addlinkedserver的@datasrc参数必须填 DSN 名，不是 IP 或连接字符串；密码要单独用sp_addlinkedsrvlogin绑定 - 跨库 JOIN 时，四部分命名必须写全：
[linked_server_name].[database_name].[schema_name].[table_name]，MySQL 没 schema，schema_name填dbo或留空（取决于驱动）
为什么跨库 JOIN 在应用层拼数据比数据库层更可控？
因为所有数据库的联邦查询都绕不开两个硬伤：事务隔离无法跨实例保证，错误传播链路长（A 库连不上 → B 库查询卡住 → 整个页面超时）。而用代码分两步查，反而容易做降级和超时控制。
- 先查主表（如订单），拿到关键 ID 列表（
order_ids = [1001, 1002]），再用IN批量查从库（用户信息），即使从库抖动，至少订单列表能出来 - 注意 MySQL 的
max_allowed_packet限制批量 ID 数量；PostgreSQL 用ANY(ARRAY[...])更安全 - 如果两个库都是同类型（比如都是 MySQL），用应用层合并还能规避字符集转换问题——数据库联邦常因远端表用
utf8mb4_0900_as_cs、本地用utf8mb4_general_ci导致JOIN结果乱码
真正难的不是语法怎么写，是搞清哪一层该承担哪部分职责：数据库只管单实例内的强一致性，跨实例的关联逻辑，越早交给应用层，越不容易在凌晨三点被报警叫醒。
