跨库查询慢的核心在于物理隔离导致的网络开销、权限限制和执行计划失控；应优先应用层聚合、建同步表、用汇总表替代实时跨库计算，严禁生产环境裸写跨库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）