原生跨库join不被支持，因数据库引擎仅管理本实例元数据、事务与执行计划，跨库导致类型校验失败、隔离级别冲突、统计信息缺失及网络延迟不可控，所有“一条sql跨库join”实为多次单库查询加中间层关联。
跨数据库实例的 JOIN 查询不能靠标准 SQL 原生实现，必须依赖中间层或数据库代理服务；直接写 SELECT * FROM db1.users u JOIN db2.orders o ON u.id = o.user_id 在 MySQL、PostgreSQL 等主流关系型数据库中会报错或静默失败。
为什么原生跨库 JOIN 不被支持
数据库引擎的查询执行器只管理本实例内的元数据、索引和事务上下文。跨库意味着：
- 表结构无法统一校验（比如 db1.users.id 是 BIGINT，db2.orders.user_id 是 VARCHAR）
- 事务隔离级别无法对齐（一个库用 READ COMMITTED，另一个用 SERIALIZABLE）
- 执行计划无法协同生成（优化器看不到远端表的统计信息）
- 网络延迟不可控（一次 JOIN 可能触发多次跨机房 RPC）
所以所有“一条 SQL 跨库 JOIN”的方案，本质都是把 JOIN 拆解成多次单库查询 + 应用层/中间件层关联。
阿里云 DMS 跨实例查询的实际用法
这是目前对业务侵入最小、语法最接近原生 JOIN 的方案，但需注意其限制：
- 必须先在 DMS 控制台为每个远端数据库创建 DBLink（如
mysql_prod、redis_cache），DBLink 名称会成为 SQL 中的数据库前缀 - JOIN 仅支持左表（驱动表）在当前实例，右表通过 DBLink 引用，例如：
SELECT u.name, o.order_id FROM users u JOIN mysql_prod.orders o ON u.id = o.user_id;
- 不支持跨 DBLink 的 WHERE 下推——
WHERE o.created_at > '2025-01-01'会被下推到远端执行，但WHERE u.status = 'active' AND o.amount > 100中的o.amount条件可能无法下推，导致拉回大量无效行 - Redis 作为右表时，只能 JOIN 到它的 key 层面（如
redis_cache.db0.hash表），不能按 hash 内部 field 关联
自建中间层替代方案的取舍点
当 DMS 不适用（比如用的是私有云或自建数据库集群），可考虑以下路径：
-
Flink CDC + 实时物化：监听各库 binlog，将用户、订单等核心表实时同步到一张宽表（如
dw_user_order_facts），查询走本地 JOIN。适合 T+1 或秒级延迟可接受的场景 -
应用层双查 + Hash Join：先查
users，提取id列表，再用IN批量查orders，在内存里用 HashMap 关联。注意IN参数不能超 1000 个，需分批 -
MySQL Federated 引擎（慎用）：在本地库建
FEDERATED表指向远端表，然后写标准 JOIN。但该引擎不支持事务、无连接池、错误堆栈不清晰，线上环境基本已被弃用
最容易被忽略的性能陷阱
即使用了 DMS 或 Flink，仍要警惕三类隐性开销：
- 远端表没索引时，DMS 会把整张
orders表拉到本地再过滤——务必确认db2.orders(user_id)有索引，且类型与本地users.id完全一致（含SIGNED/UNSIGNED） - 跨地域查询（如华东 DB 查华北 Redis）默认走公网，延迟常超 50ms；必须在 DMS 中开启 VPC 内网直连，并确认安全组放行
- 结果集超过 10 万行时，DMS 默认分页拉取，但每次分页都重跑远端查询——应加
LIMIT并确保ORDER BY字段在远端有索引，否则排序在本地做，内存爆掉
