GROUP BY 性能优化核心是减少数据量、加速分组定位、避免冗余计算；需建覆盖索引、前置 WHERE 过滤、控制分组粒度、用汇总表或物化视图替代实时聚合，并通过 EXPLAIN 诊断瓶颈。
GROUP BY 是 SQL 中最常用也最容易拖慢查询性能的操作之一。它本质需要对数据进行分组、排序（隐式或显式）、聚合计算，若数据量大、分组字段无索引、或聚合逻辑复杂，很容易出现全表扫描、临时表溢出、磁盘排序等问题。优化核心在于：减少参与分组的数据量、加速分组定位、避免不必要的计算。
确保 GROUP BY 字段有高效索引
数据库通常无法直接利用普通索引加速分组，但若索引覆盖了 GROUP BY 列 + 所有 SELECT 中的非聚合列（即“覆盖索引”），就能避免回表，大幅提升效率。
- 例如：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id，应在(user_id)上建索引；若改为SELECT user_id, status, COUNT(*) FROM orders GROUP BY user_id, status，则需联合索引(user_id, status)。 - 注意：MySQL 8.0+ 支持松散索引扫描（Loose Index Scan）优化某些 MIN/MAX/COUNT 场景，但前提是索引顺序与 GROUP BY 完全一致且无 WHERE 过滤干扰。
- 避免在 GROUP BY 字段上使用函数或表达式（如
GROUP BY YEAR(create_time)），这会强制放弃索引，应改用范围条件 + 预计算字段或物化列。
提前过滤，缩小输入数据集
在 GROUP BY 之前，用 WHERE 尽可能剔除无关行。HAVING 是分组后过滤，开销远高于 WHERE。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 错误写法：
SELECT dept, AVG(salary) FROM emp GROUP BY dept HAVING AVG(salary) > 10000（先分组全部部门，再筛） - 优化思路：若业务允许，可先用 WHERE 锁定高薪人群范围（如
WHERE salary > 8000），再分组；或结合分区表按时间/地域预切片。 - 对大表，考虑是否能用 EXISTS 或半连接替代某些带子查询的 GROUP BY 场景，减少中间结果集大小。
控制分组粒度与聚合复杂度
分组键越少、值越离散，分组桶数越少，内存压力越小；聚合函数越简单（COUNT、SUM），越容易被引擎优化。
- 避免
GROUP BY CONCAT(first_name, ' ', last_name)这类字符串拼接分组——既无法走索引，又增加 CPU 和内存负担。应预先计算并存入冗余字段加索引。 - 慎用 DISTINCT + GROUP BY 组合（如
COUNT(DISTINCT user_id)），该操作常触发临时表和文件排序。MySQL 8.0+ 可考虑用 HyperLogLog 近似算法（如APPROX_COUNT_DISTINCT）权衡精度与性能。 - 聚合字段尽量不包含大字段（如 TEXT、JSON），否则排序/哈希过程极易内存溢出，导致写磁盘临时表。
善用物化中间结果与汇总表
对于高频、低频更新的统计类查询（如日报销量、用户活跃度），不要每次都实时 GROUP BY 原始明细表。
- 建立按天/小时粒度的汇总表（如
sales_daily(dept_id, product_id, sale_cnt, revenue)），写入时聚合，查询时直接读汇总表。 - 利用 MySQL 的物化视图替代方案（如定时任务 + REPLACE INTO）、或 PostgreSQL 的物化视图（9.4+）、ClickHouse 的物化视图引擎。
- 对实时性要求不高的报表，可将 GROUP BY 查询结果缓存到 Redis 或本地文件，设置合理过期策略。
不复杂但容易忽略：执行前务必看执行计划（EXPLAIN），重点关注 type 是否为 index/const、Extra 是否含 Using temporary; Using filesort。这些是性能瓶颈最直接的信号。
