同一实例下跨库JOIN合法且无需插件，但需带库前缀、反引号正确包裹、权限齐全；跨实例禁用FEDERATED，应采用应用层分步查询+内存聚合；注意字符集、索引、事务隔离及权限校验。
同一实例下用 db_name.table_name 直接 JOIN 就行
只要两个库在同一个 mysqld 进程里（同服务器、同端口），SELECT u.name, o.amount FROM user_db.users u JOIN order_db.orders o ON u.id = o.user_id 这种写法完全合法，不需要额外配置或插件。MySQL 原生支持，5.7 和 8.0 都没问题。
但必须注意：所有跨库字段在 ON 子句里都要带库前缀，比如 ON user_db.users.id = order_db.orders.user_id；写成 users.id = orders.user_id 会报 Unknown column 'users.id' in 'on clause' —— 因为 MySQL 不知道你指哪个库的 users。
反引号要分别包库名和表名：`user_db`.`users` 合法，`user_db.users` 是错的（会被当做一个带点的表名）。
权限也得配齐：执行用户必须同时有 user_db 和 order_db 的 SELECT 权限，漏掉一个就会报 ERROR 1142 (42000): SELECT command denied。
跨实例时别碰 FEDERATED 引擎
FEDERATED 在 MySQL 8.0 已默认禁用，5.7 需手动编译启用，生产环境基本没人敢用。它每次查询都新建 TCP 连接，无连接复用，高并发下直接打挂远程库；错误信息极不友好，比如 ERROR 1429 (HY000): Unable to connect to foreign data source，根本分不清是 DNS 失败、认证失败还是超时。
更致命的是事务不可控：本地 ROLLBACK 对 Federated 表无效，远程写操作早已提交；远程表结构变更后，本地 SHOW CREATE TABLE 可能返回过期定义甚至直接报错。
如果你看到文档里还提 FEDERATED，基本是过时资料。2026 年的真实生产环境，它只是个历史名词。
应用层聚合才是现实选择
跨实例场景下，真正落地的方式是应用层分步查 + 内存 join：
- 先查主表（如
users），控制单次 ID 数量 ≤ 1000，避免IN列表过大 - 再用这批 ID 批量查从表（如
WHERE user_id IN (...)），注意字段加索引 - 代码里以关联字段（如
user_id）为 key 构建哈希映射，做内存级合并 - 显式处理空值逻辑：用户无订单、订单被软删、时间范围过滤等，都不能依赖 SQL 自动补空
- 高频结果建议加缓存，比如用
user:123:recent_orders这类 key
这种方案可控、可监控、可降级，比硬塞一条跨实例 SQL 强得多。
容易被忽略的性能陷阱
同一实例跨库 JOIN 看似和单库一样快，但实际容易踩坑：
- 数据物理分散导致 buffer pool 命中率下降，IO 放大，EXPLAIN 显示
type=ref≠ 实际快 - 字符集或排序规则不一致（如
utf8mb4_0900_as_csvsutf8mb4_general_ci）会触发隐式转换，索引直接失效 - 事务无法跨库回滚：在一个事务里更新
db1.t1和db2.t2，失败时只能保证本库回滚，另一库变更已提交 - 视图里用跨库表名可以，但迁移时目标实例必须有同名库+结构一致的表，否则
SELECT直接报Table 'db2.orders' doesn't exist
最常被跳过的其实是权限验证和字符集对齐——这两点不出错则已，一出就是线上事故。
