跨库统计慢的核心解法是引入中间层聚合：T+1报表用ETL+宽表预聚合（如StarRocks），准实时看板用Flink流式聚合，强一致查询则通过路由层并发分发+内存合并。
跨库统计慢，核心问题不是SQL写得不好，而是数据库无法跨实例做高效关联和聚合。直接在应用层拉取多库数据再计算，容易OOM或超时；用联邦查询（如MySQL FEDERATED、PostgreSQL FDW）又受限于网络延迟、权限隔离和执行计划失控。真正可行的解法是引入中间层聚合——把实时性要求不高的统计逻辑，下沉到一个可控、可扩展的中间计算层完成。
用ETL+宽表预聚合，扛住高频查询
对T+1或小时级更新的报表，放弃“查时计算”，改用定时任务从各业务库抽取关键字段（如订单ID、商户ID、金额、时间戳），清洗后写入统一的数据仓库（如StarRocks、Doris、ClickHouse）或Hive宽表。一张宽表包含所有维度和指标，查询时只需单表扫描，响应从分钟级降到毫秒级。
- 每天凌晨2点调度Airflow任务，拉取昨日全量订单+支付+退款三库数据，按商户+日期+状态做SUM/ COUNT聚合，生成dws_merchant_daily_summary宽表
- 报表接口不再JOIN多库，只查这张宽表，加索引后QPS提升20倍，且支持下钻到任意维度组合
- 注意：宽表需保留明细主键（如order_id）以便溯源，避免纯汇总丢失原子信息
实时链路走轻量消息+流式聚合
对需要准实时（秒级到分钟级）的看板，用Flink或Spark Streaming监听各库的binlog（通过Canal/Debezium接入），将变更事件按业务主键（如user_id、shop_id）分组，在内存或RocksDB状态后端做增量聚合（如SUM、COUNT、TOP N），结果写入Redis或OLAP引擎供查询。
- 订单库下单事件 → Flink KeyBy(order_id) → 实时更新redis:hll:shop_20240515去重计数
- 支付成功事件 → 按merchant_id累加金额 → 写入Doris的实时聚合表，自动合并小批次
- 避免全量拉取：只同步变更字段，不传blob/text大字段，减少网络和序列化开销
查询路由层做透明分流与结果合并
当必须查原始库（比如审计类强一致场景），在DAO或API网关层加一层逻辑路由：识别SQL中的库/表前缀或租户ID，拆解为多个子查询并发发往对应库，拿到结果后在JVM内存中做union、group by或top-k合并。不依赖数据库能力，完全由应用控制。
- 报表请求带参数region=sh,region=bj → 自动路由到sh_db和bj_db两个数据源
- 用CompletableFuture并发执行，超时阈值设为3s，任一库失败则降级返回缓存结果
- 合并时注意时区、精度（decimal vs double）、NULL处理逻辑统一，避免sum结果偏差
中间层聚合不是银弹，但能明确划分责任边界：原始库专注事务，中间层专注分析，查询层专注呈现。选型时优先复用现有技术栈（比如已有Flink就别硬上Kafka Streams），重点保障聚合口径一致性与数据延迟可监控。
