跨库查询慢的核心在于物理隔离导致的网络开销、权限限制和执行计划失控；应优先应用层聚合、建同步表、用汇总表替代实时跨库计算，严禁生产环境裸写跨库 sql。
跨库查询慢，核心问题不在 SQL 本身，而在数据物理隔离带来的网络开销、权限限制和执行计划不可控。直接跨库 JOIN 或子查询通常无法走索引下推，容易触发全表扫描 + 大量数据拉取，性能急剧下降。真正有效的优化方向是减少跨库动作，把“查”变成“读”。
优先用应用层聚合替代数据库层 JOIN
当需要关联 A 库的用户表和 B 库的订单表时，不要写SELECT * FROM A.users u JOIN B.orders o ON u.id = o.user_id。改成两步：先查出目标用户 ID 列表（带必要过滤），再用这些 ID 批量查 B 库订单。这样能复用各自库的索引，避免跨库传输冗余字段和中间结果集。
- 用户 ID 列表控制在 1000 以内，避免 B 库 IN 语句过长；超量时分批处理
- 查订单时只 SELECT 业务必需字段，禁用 SELECT *
- 应用中用 HashMap 或类似结构本地关联，比数据库 JOIN 更可控
建立轻量级同步表，按需预计算
对变化不频繁、查询高频的维度数据（如地区、品类、状态码），在主报表库中建一张只读同步表，每天凌晨通过定时任务拉取源库快照。查询时完全本地 JOIN，零跨库延迟。
- 同步脚本用INSERT INTO … SELECT … FROM remote_db.table（需已配置 DBLink 或 FEDERATED 引擎）
- 加 ON DUPLICATE KEY UPDATE 或先 TRUNCATE 再 INSERT，保证幂等
- 表上建好联合索引，匹配报表常用 WHERE+ORDER 组合
用物化视图或汇总表替代实时跨库计算
如果报表依赖跨库聚合（如“各区域近 30 天销售额”），不要每次请求都 SUM 跨库订单。改为每日凌晨跑一次 ETL：从订单库拉取当日数据，按区域 + 日期分组写入报表库的汇总表。查询直接读这张宽表。
- 汇总粒度根据报表需求定，避免过度细分导致表膨胀
- 保留原始订单 ID 数组或数量字段，支持下钻到明细
- 同步失败时有告警，汇总表加 last_update_time 字段便于排查
必须跨库时，用 DBLink 或 FEDERATED 严格限制范围
仅限临时分析或低频后台任务启用跨库能力。生产报表严禁裸写跨库 SQL。启用前确认：目标库已建好覆盖查询条件的索引；网络延迟稳定低于 10ms；连接池配置合理，避免打满远端库连接数。
- MySQL 用 FEDERATED 表，建表语句中指定远程连接串和真实表名
- PostgreSQL 用 dblink_exec 或 postgres_fdw，查询时显式指定远程 schema
- 所有跨库操作包装进存储过程，统一加超时控制（如 statement_timeout=30s）
