SQL跨库JOIN无法直接执行，需通过应用层聚合、定时ETL同步至数仓或联邦查询引擎实现；不推荐拼接SQL、N+1查询及DBLink等方案。
SQL跨库JOIN无法直接执行，因为标准SQL不支持跨数据库（尤其是不同实例）的表关联。解决这个问题的核心思路是：把数据“拉到一起”再计算，而不是在查询时实时跨库关联。
方案一：应用层聚合（最常用）
在业务代码中分别查询各库的数据，然后在内存或中间层做关联和计算。
- 适合读多写少、数据量不大（单次结果集几千行内）、实时性要求高的场景
- 用Map结构缓存主表ID → 记录，再遍历从表数据按外键匹配，比嵌套循环高效
- 注意分页问题：不能直接limit，需先取足主表数据，再关联补全，最后再分页裁剪
- Java可用Stream API、Python可用pandas merge，但要注意内存占用
方案二：定时ETL同步到统一数仓
将多个业务库的表定期（T+1 或分钟级）同步到一个中心化数据库（如MySQL分库汇总库、StarRocks、Doris、ClickHouse）后再JOIN。
- 用Flink CDC、Canal、DataX或自研binlog解析服务捕获变更
- 同步时建议加时间戳字段（如sync_time），便于排查延迟和幂等处理
- 关键表可建宽表（如订单+用户+商品信息合并为dwd_order_full），避免运行时JOIN
- 适合报表、BI分析、离线统计等对实时性容忍度较高的场景
方案三：联邦查询引擎（技术门槛略高）
借助支持跨源查询的中间件，在SQL层屏蔽底层存储差异，实现“逻辑上”的跨库JOIN。
- Apache Doris、StarRocks、Trino（PrestoSQL）、TiDB 7.0+ 的 MySQL 兼容模式都支持外部表或外表JOIN
- 例如在Doris中创建MySQL外表，再与本地表JOIN，SQL写法不变，执行计划由引擎优化
- 注意网络开销和权限配置：需确保查询节点能直连目标库，且账号有SELECT权限
- 适合已有成熟数仓底座、希望复用SQL能力、且能接受一定查询延迟（秒级）的团队
不推荐的做法
强行用程序拼接SQL或在应用里嵌套N+1查询——性能差、难维护、易超时；或者用DBLink（Oracle）、FEDERATED引擎（MySQL旧版）——稳定性弱、功能受限、运维成本高，生产环境慎用。
