跨库 JOIN 在单机数据库中无法高效执行，因网络延迟、内存压力及缺乏下推优化；可行方案为应用层拼接或分布式查询引擎（如TiDB、Doris、StarRocks），需关注数据裁剪、类型一致、权限配置与执行计划调优。
跨库 JOIN 在 MySQL / PostgreSQL 里根本跑不起来
单机数据库默认不支持跨库 JOIN——不是语法报错，而是执行时直接失败或返回空结果。MySQL 的 FEDERATED 引擎、PostgreSQL 的 postgres_fdw 虽然能“连”，但实际是把远程表当本地视图拉取全量数据再 join，网络+内存双重压力下，10 万行就卡死。
- MySQL 启用
FEDERATED后执行SELECT * FROM db1.t1 JOIN db2.t2 ON t1.id = t2.ref_id，底层会先SELECT * FROM db2.t2拉到本地临时表，再 join；t2 有 50 万行？内存爆掉前先等 3 分钟 - PostgreSQL +
postgres_fdw默认不下推WHERE条件，哪怕你只查id = 123，它也会把整张远程表拖回来再过滤 - 所有跨库 join 都绕不开网络延迟，RTT 20ms × 多轮请求，比本地磁盘 IO 还慢
真正能用的方案只有两种：应用层拼接 or 分布式查询引擎
别纠结“让 SQL 自己跨库”，得换思路。要么在代码里分两步查再内存 join（适合中小数据量），要么交给专干这事的系统（如 TiDB、Doris、StarRocks）。
- 应用层拼接：先查
SELECT id, name FROM db1.users WHERE status = 'active'，拿到 2000 个id，再用IN查SELECT user_id, order_time FROM db2.orders WHERE user_id IN (…)；注意IN列表长度限制（MySQL 默认 1000，可调max_allowed_packet） - TiDB 支持跨库
JOIN，但要求两张表都建在 TiDB 集群内（即数据已同步过去），不是直连原 MySQL 实例；本质是统一元数据 + 分布式执行计划，不是“代理” - Doris 的
MySQL外表可以映射远端表，但 join 时仍需手动指定distributed_join=true才触发下推，否则又变成本地拉全量
分布式 JOIN 性能陷阱：数据倾斜和广播开销
就算用了 Doris 或 StarRocks，JOIN 也不是无脑写就能快。大表关联小表时，引擎默认可能把小表广播到所有节点，但如果小表其实有 2GB，广播反而拖垮集群。
- 检查执行计划：Doris 用
EXPLAIN看是否出现BROADCAST；若小表实际 >1GB，强制改用SHUFFLE（按 join key 重分布） - 避免
SELECT *：跨库 join 前先用WHERE和LIMIT缩减数据集，Doris 对外表字段裁剪不敏感，多查一列就多传一列 - 时间字段类型要一致：MySQL 的
DATETIME和 Doris 的DATETIME看似一样，但时区处理不同，join 结果可能为空——得统一转成STRING或显式CONVERT_TZ
别忽略权限和连接稳定性
外表、FDW、FEDERATED 这些机制全依赖远程数据库的账号权限，且连接一旦中断，整个 query 就失败，不像本地表能重试。
- MySQL
FEDERATED表必须用远程库的账号密码建表：CREATE TABLE t2 (…) ENGINE=FEDERATED CONNECTION='mysql://user:pass@host:3306/db2/t2'；密码硬编码在表定义里，运维极不友好 - PostgreSQL
postgres_fdw需提前创建USER MAPPING，且远程库账号必须有SELECT权限——但很多人只给了publicschema 权限，忘了pg_catalog也要授权，否则ANALYZE失败导致统计信息不准、join 走错计划 - Doris 的 MySQL 外表不支持连接池，每个 query 都新建连接，远程库 max_connections 不够时直接报
Too many connections
事情说清了就结束。跨库 JOIN 的核心从来不是“怎么写 SQL”，而是“谁来承担数据移动的成本”——数据库、中间件、还是你的应用代码。选错承担方，优化再细也没用。
