SQL分组统计效率取决于数据量、索引设计、分组字段选择和提前过滤；应优先用WHERE而非HAVING过滤，建立覆盖索引（WHERE字段→GROUP BY字段→SELECT非聚合字段），避免冗余分组字段，并在大数据量时采用预聚合或物化视图。
SQL分组统计核心靠 GROUP BY 搭配聚合函数（如 COUNT、SUM、AVG 等），但真正影响效率的，往往不是写法对不对，而是数据量、索引设计、分组字段选择和是否提前过滤这些细节。
先筛再分：WHERE 一定要在 GROUP BY 前用
很多人习惯先把所有数据 GROUP BY，再用 HAVING 过滤分组结果——这会极大拖慢速度，尤其表大时。HAVING 是对已分组后的结果再筛选，意味着数据库得先完成全部分组计算，哪怕你最后只想要其中 1% 的组。
- ✅ 正确做法：把能用 WHERE 过滤的条件（比如时间范围、状态值、ID区间）全写在 GROUP BY 前面
- ❌ 避免滥用 HAVING：除非必须依赖聚合结果（例如“订单总金额 > 10000”的客户），否则别用它做基础条件筛选
- 示例：WHERE order_date >= '2024-01-01' 要比 HAVING MAX(order_date) >= '2024-01-01' 快得多
索引要覆盖：分组字段 + 过滤字段 + 查询字段
数据库执行 GROUP BY 时，如果没合适索引，就会触发临时表 + 文件排序（Using temporary; Using filesort），这是性能杀手。
- 最理想情况：建联合索引，顺序按 WHERE 字段 → GROUP BY 字段 → SELECT 中的非聚合字段 排列
- 比如查询 SELECT city, COUNT(*) FROM users WHERE status = 1 GROUP BY city;，推荐索引：(status, city)
- 若还用到 AVG(age)，且 age 经常参与计算，可考虑扩展为 (status, city, age)（覆盖索引）
少分组、少字段：避免“假性分组”和冗余列
有些写法看似合理，实则让分组粒度变细、结果膨胀，徒增计算负担。
- 别把唯一字段（如 id、order_no）放进 GROUP BY——除非真需要按它分，否则直接去掉
- SELECT 中只放 GROUP BY 字段 + 聚合函数；避免混入未聚合的普通列（MySQL 5.7+ 默认报错，老版本可能返回随机值）
- 如果只是想“去重计数”，优先用 COUNT(DISTINCT col)，而不是 GROUP BY col + COUNT(*) 再套一层子查询
大数据量时：考虑预聚合或物化视图
当单表千万级以上、且分组统计被高频调用（如后台报表、BI看板），实时计算代价太高。
- 每天凌晨跑一次汇总表：比如按天/地区/品类预存销售总额、订单数，查时直接读汇总表
- 用定时任务更新增量：只处理新增或变更的数据，避免全量重算
- 部分数据库（如 PostgreSQL、MySQL 8.0+ 配合第三方工具）支持物化视图，自动维护聚合结果
基本上就这些。分组统计不复杂，但容易忽略执行路径和数据特征。写完 SQL 别急着上线，用 EXPLAIN 看一眼执行计划，重点关注是否用上索引、有没有 Using temporary，比调优一百行代码都管用。
