SQL报表查询慢的核心在于数据组织与访问路径不匹配；需协同宽表设计（按高频维度/指标预聚合）与组合索引（覆盖过滤、排序、分组），避免盲目宽表和冗余索引。
SQL报表查询慢，核心往往不是SQL写得差，而是数据组织方式和访问路径没对上。宽表设计和索引策略不是二选一，而是要协同：宽表减少多表关联，索引加速关键过滤与排序，两者配合才能让报表既快又稳。
宽表不是“把所有字段堆一起”，而是按报表场景预聚合
盲目宽表反而拖慢写入、浪费存储、增加维护成本。真正有效的宽表，是围绕高频、固定维度（如日期、部门、产品线）和常用指标（如销售额、订单量、UV）做轻度聚合或关联固化。
- 区分“事实宽表”和“维度宽表”：事实宽表保留明细粒度但补全常用维度字段（如订单表+客户等级+区域名称）；维度宽表则做汇总（如日销售汇总表含当日各省各品类的GMV、订单数）
- 避免实时JOIN：把原本需要JOIN 4张表才能出的报表字段，提前在ETL中打平到一张宽表里，查询时单表扫描即可
- 注意更新一致性：宽表字段来源需明确主表，比如客户等级以CRM系统为准，不能因订单表临时更新而错乱
索引不是“给WHERE字段都加上”，而是匹配查询模式建组合索引
报表查询通常有固定入口，比如“查某省某月TOP10商品”，这类查询的过滤条件、分组字段、排序字段就是索引设计的黄金线索。
- 优先覆盖“过滤+排序+分组”三要素：例如查询语句含 WHERE province = ? AND dt >= ?，ORDER BY sales_amt DESC，那索引宜建为 (province, dt, sales_amt)
- 避免冗余单列索引：(a)、(b)、(a,b)三个索引不如一个(a,b)高效，后者可同时支持 WHERE a=?、WHERE a=? AND b=?、ORDER BY a,b 等多种场景
- 谨慎使用函数索引：如 WHERE DATE(create_time) = '2024-01-01' 会导致索引失效，应改写为 create_time >= '2024-01-01' AND create_time
宽表+索引还要配合理分区与冷热分离
报表数据天然有时效性，近3个月查得勤，3年前基本只归档不用。不加区分地建索引或放宽表，会让热点查询被冷数据拖累。
- 按时间分区：宽表按月/周分区，既能加快范围查询（如只扫202404分区），也方便自动清理历史数据
- 冷热字段拆分：把高频访问字段（如订单状态、金额、时间）留在主宽表，低频字段（如备注、原始日志JSON）单独存为扩展表，用主键关联，避免每次查询都加载大字段
- 索引按需启用：对历史分区可禁用非必要索引，降低写入开销；对当前活跃分区确保关键索引在线
验证效果比建得多更重要：用执行计划说话
别依赖经验猜，每建一张宽表、每加一个索引，都要看实际执行计划是否走索引、是否回表、是否用到分区裁剪。
- MySQL用 EXPLAIN FORMAT=TRADITIONAL；PostgreSQL用 EXPLAIN (ANALYZE, BUFFERS)；ClickHouse用 EXPLAIN PLAN
- 重点关注：type是否为 const/ref/range（避免ALL）、key是否命中预期索引、rows是否显著减少、Extra是否有 Using filesort / Using temporary（说明排序或聚合未走索引）
- 上线前压测真实报表SQL，对比优化前后QPS、平均耗时、P95延迟，尤其关注并发场景下锁等待和内存使用
