跨库 JOIN 在单机数据库中必然慢或失败，因其不原生支持，FEDERATED/postgres_fdw 会全量拉取远程表再本地 join，导致内存溢出、网络延迟高、条件不下推；应用层拼接更稳妥，同时需注意类型一致、权限及连接稳定性。
跨库 JOIN 在 MySQL、PostgreSQL 这类单机数据库里根本跑不起来，不是语法报错，而是执行时要么卡死、要么返回空或错误结果——别浪费时间调优 SQL，先确认你是不是在用错工具。
为什么跨库 JOIN 一定会慢甚至失败
单机数据库默认不支持跨库 JOIN。MySQL 的 FEDERATED 引擎、PostgreSQL 的 postgres_fdw 虽然能“连”，但本质是把远程表全量拉到本地再 join：
- MySQL 执行
SELECT * FROM db1.t1 JOIN db2.t2 ON t1.id = t2.ref_id，底层会先SELECT * FROM db2.t2拉到临时表；t2 有 50 万行？内存爆掉前先等 3 分钟 - PostgreSQL +
postgres_fdw默认不下推WHERE条件，哪怕你只查id = 123，它也会把整张远程表拖回来再过滤 - 网络 RTT 20ms × 多轮请求，比本地磁盘 IO 还慢；一次 JOIN 往往触发多次 round-trip
应用层拼接：中小数据量最稳的方案
适合主表结果集可控（
- 第一步查主表：
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 默认max_allowed_packet=4MB，实际能塞约 1000 个 INT；可调大，但别超 16MB - 别直接
SELECT *拼接，先只取关联键和必要字段；大文本字段（如detail_text）必须剥离到后续单独查
分布式查询引擎：大流量、高一致性场景唯一可行路径
TiDB、Doris、StarRocks 是目前真正支持跨库 JOIN 的生产级方案，但它们的前提不是“直连原库”，而是“数据已统一纳管”：
- TiDB 要求两张表都建在 TiDB 集群内（即数据已同步过去），不是代理原 MySQL 实例；本质是统一元数据 + 分布式执行计划
- Doris 的 MySQL 外表能映射远端表，但
JOIN时必须显式加distributed_join=true才触发下推，否则又变成本地拉全量 - 检查执行计划：Doris 用
EXPLAIN看是否出现BROADCAST；若小表实际 >1GB，强制改用SHUFFLE（按 join key 重分布），否则广播会拖垮集群 - 时间字段类型要一致：MySQL 的
DATETIME和 Doris 的DATETIME时区处理不同，JOIN结果可能为空——得统一转成STRING或显式CONVERT_TZ
最容易被忽略的是权限与连接稳定性：跨库操作依赖远端库的账号权限、网络白名单、连接池配置；一个 max_connections 不够或防火墙策略收紧，就直接中断，且错误日志往往藏在远端节点，本地查不到。
