sql报表聚合慢的核心是数据扫描大、中间结果膨胀、过滤低效；应优先在where中强过滤（如时间范围、状态码），避免having后筛，减少参与聚合行数。
SQL报表中聚合函数执行慢，核心问题往往不在函数本身，而在于数据扫描范围大、中间结果膨胀、缺乏有效过滤或索引支持。优化关键不是替换COUNT或SUM，而是减少参与聚合的行数和提升访问效率。
提前过滤：WHERE比HAVING更高效
HAVING作用于分组后结果，意味着数据库必须先完成全量分组再筛选；WHERE则在聚合前就剔除无关行，大幅降低计算量。
- 把时间范围、状态码、业务类型等强筛选条件写在WHERE子句中，而非留到HAVING里
- 避免
HAVING COUNT(*) > 1这类低效写法，若目标是查“有多个订单的客户”，优先用子查询或窗口函数预判 - 对日期字段使用确定区间（如
order_time >= '2024-01-01' AND order_time ），比<code>YEAR(order_time)=2024更易走索引
精简GROUP BY字段：少列=少分组=少内存
每多一个GROUP BY字段，分组数量可能呈指数级增长，导致哈希表膨胀、磁盘临时文件增多、CPU缓存失效。
- 确认是否真需要按
create_time秒级分组？尝试按小时或天截断（DATE(create_time)）再聚合 - 避免在GROUP BY中包含长文本、JSON字段或无业务意义的ID（如日志流水号）
- 若仅需统计总数，不用GROUP BY时直接用聚合函数；若只需某类汇总，用
GROUP BY category而非GROUP BY category, user_id, order_no
善用覆盖索引与物化视图
当聚合只涉及少数几列（如SUM(amount) GROUP BY status），可建覆盖索引让引擎免去回表；高频固定报表可预计算并持久化。
- 为常用聚合场景建联合索引，顺序按GROUP BY字段 + 聚合字段，例如：
INDEX idx_status_amount (status, amount) - MySQL 8.0+ 或 PostgreSQL 可用物化视图（或定期刷新的汇总表）存储日/周粒度销售汇总，报表直接查汇总表
- ClickHouse、Doris等OLAP引擎支持预聚合表（ReplacingMergeTree、AggregateTable），自动合并明细数据
拆分复杂聚合：用子查询或CTE控制中间集大小
一个含多层JOIN+GROUP BY+窗口函数的大SQL，容易触发内存溢出或执行计划退化。主动拆解可提升可控性。
- 先用子查询提取关键中间结果（如“近30天有效订单ID列表”），再与主表关联聚合
- 用CTE明确逻辑分层，便于数据库优化器估算行数，也方便人工定位瓶颈步骤
- 对超大数据集，考虑分批次聚合（如按日期分区循环处理），再用UNION ALL合并结果
不复杂但容易忽略：检查执行计划中的rows_examined和Extra字段，确认是否出现Using temporary; Using filesort——这往往是优化切入点。
