报表SQL性能调优核心是减少扫描量、避免重复计算、合理用索引、控制结果集；需精简SELECT字段、WHERE提前过滤、慎用HAVING、构建匹配查询模式的复合索引。
报表SQL性能调优，核心在于减少数据扫描量、避免重复计算、合理利用索引，并控制结果集规模。不优化的统计报表容易拖慢整个业务系统，尤其在数据量大、并发高时表现明显。
精简SELECT字段，避免SELECT *
统计报表常习惯写 SELECT *，但实际只需几个聚合字段（如 SUM(amount)、COUNT(*)、GROUP BY region）。全字段查询会增加I/O、网络传输和内存开销，还可能让优化器放弃使用覆盖索引。
- 只查真正需要的列，特别是去掉大字段（如TEXT、JSON、BLOB）
- 用具体字段替代 *，例如：SELECT dept_id, COUNT(*), AVG(salary) FROM emp GROUP BY dept_id
- 若需关联多表，确认每张表只取必要字段，避免隐式笛卡尔积风险
WHERE条件提前过滤，慎用HAVING
HAVING 是在 GROUP BY 之后执行的，意味着它必须先算出全部分组结果再筛选；而 WHERE 可在聚合前就大幅减少数据量。能用 WHERE 的逻辑，不要挪到 HAVING。
- 把时间范围、状态码、部门ID等高区分度条件放在 WHERE 中，例如：WHERE create_time >= '2024-01-01' AND status = 1
- 避免在 HAVING 中写复杂表达式，如 HAVING SUM(amount) > (SELECT …)，应考虑改写为子查询或临时表
- 注意 NULL 值对 WHERE 和 HAVING 的影响，必要时显式加 IS NOT NULL
善用索引，重点覆盖WHERE+GROUP BY+ORDER BY
统计类SQL最常走全表扫描，主因是缺少合适索引。复合索引设计要匹配查询模式，顺序很重要。
- 优先建在 WHERE 条件字段上（尤其是等值查询+范围查询组合）
- 如果含 GROUP BY 或 ORDER BY，将相关字段追加到索引末尾，例如：INDEX (status, create_time, dept_id) 可支撑 WHERE status=1 AND create_time > '…' GROUP BY dept_id
- 避免在索引字段上做函数操作，如 YEAR(create_time) = 2024 会失效索引，改用 create_time >= '2024-01-01' AND create_time
拆分复杂报表，用中间表或物化视图降压
单条SQL既要JOIN五张大表，又要多层嵌套聚合，执行计划极易失控。对高频、固定口径的统计报表，可预计算并持久化中间结果。
- 每日凌晨跑批生成汇总表（如 daily_sales_summary），报表直接查该表
- 用临时表或CTE分步处理，比如先过滤出目标用户，再关联订单统计，比一气呵成更易优化
- 部分数据库支持物化视图（如 PostgreSQL 9.4+、Oracle、Doris），自动刷新+索引支持，适合准实时场景
报表SQL不是越“炫技”越好，而是越贴近真实访问路径、越克制越高效。从执行计划看是否走了索引、有没有临时表/文件排序、扫描行数是否合理，比调参数更管用。
