分库分表SQL报表优化核心是下推执行、轻量聚合、规避跨节点JOIN：强制路由字段入参并截断时间粒度；SUM/COUNT等聚合及GROUP BY（含分片键）、ORDER BY LIMIT须下推至分片；用冗余字段、宽表预计算或分批IN替代跨库JOIN；通过SQL指纹缓存、物化视图和冷热分离降压。
分库分表后，SQL报表查询面临路由分散、结果聚合低效、跨节点JOIN缺失等核心问题。优化关键在于：让查询尽可能下推到单库单表执行，减少跨节点数据搬运；在中间层做轻量、确定性高的聚合；避免全量拉取再计算。
精准路由：让SQL命中目标分片
报表查询常因参数模糊（如日期范围过大、用户ID未传）导致路由失效，被迫广播到所有分片。应做到：
- 强制要求关键路由字段（如 tenant_id、org_code、date_part）必须入参，且校验非空；
- 对时间类报表，按分表键（如 order_date）自动截断为最小有效粒度（如只查2024-Q3 → 路由到 q3_2024 表，而非扫描全部月表）；
- 使用Hint或自定义注释（如 /* sharding: user_id=12345 */）显式指定分片，绕过复杂解析逻辑。
聚合下推：在分片内完成可并行计算
SUM/COUNT/AVG/MIN/MAX、GROUP BY（单字段且分片键参与）、ORDER BY LIMIT 等操作，必须下推至各分片本地执行，中间层只做最终合并：
- COUNT(*) → 各分片返回 count，网关累加；
- GROUP BY city → 若 city 不是分片键，需改写为两阶段：先按分片键+city局部分组，再全局 merge sort + 再分组；
- LIMIT 100 → 每个分片返回 top 100，网关归并取全局 top 100（注意 offset 分页需各分片返回更多数据）。
规避跨库JOIN与子查询膨胀
报表中常见的“订单+用户+商品”多表关联，在分库分表下无法直接执行。替代方案有：
- 冗余维表字段：在订单表中冗余 user_name、product_category，避免实时JOIN；
- 异步宽表预计算：用Flink/Spark每日生成 {order_id, user_level, product_price, region} 宽表，按 order_id 分片，报表直查；
- 主键IN查询分批：若必须关联，先查出user_id列表（路由明确），再按分片批量 IN 查询用户信息，应用层组装。
缓存与物化：降低重复报表压力
固定周期（如日/周报）、参数稳定的报表，不应每次重算：
- 结果集缓存：按SQL指纹（去空格、参数哈希）缓存JSON结果，TTL匹配业务时效（如日报缓存24h）；
- 物化视图代理：在中间件层创建逻辑视图，背后自动维护汇总表（如 daily_sales_by_region），查询走物化表；
- 冷热分离：历史报表数据归档至列存引擎（如Doris/StarRocks），查询路由自动识别并切流。
不复杂但容易忽略：路由规则和聚合策略必须和分库分表的物理拓扑严格对齐，任何配置漂移都会引发数据错误或性能雪崩。
