GROUP BY变慢主因是隐式排序、临时表和全字段扫描；有效索引需满足最左前缀+覆盖+顺序匹配；高基数分组宜用物化视图或窗口函数替代。
GROUP BY 为什么会变慢
根本原因不是 GROUP BY 本身，而是它触发的隐式排序、临时表和全字段扫描。MySQL 5.7 默认对 GROUP BY 强制排序（ORDER BY 同字段），即使你加了 ORDER BY NULL，优化器仍可能因缺少索引而回表或使用磁盘临时表。PostgreSQL 则更依赖哈希聚合，但若内存不足（work_mem 过小），会退化为外排，I/O 暴涨。
哪些索引能真正加速 GROUP BY
有效索引必须满足「最左前缀 + 覆盖 + 顺序匹配」：索引字段顺序要和 GROUP BY 列一致，且最好包含后续 SELECT 中的非聚合列（避免回表）。例如：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;
用 INDEX(user_id) 就够；但如果写成：
SELECT user_id, status, COUNT(*) FROM orders GROUP BY user_id, status;
就必须是 INDEX(user_id, status)，反过来无效。另外，status 是枚举值时，加在索引末尾还能顺便支持 WHERE status = 'paid' 条件下推。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
聚合函数引发的隐式性能陷阱
COUNT(*) 和 COUNT(1) 在 InnoDB 下基本无差别，但 COUNT(column) 会过滤 NULL，导致无法走索引覆盖（除非该列定义为 NOT NULL）。更危险的是 GROUP_CONCAT() 或 JSON_AGG()：它们默认受限于 group_concat_max_len 或内存分配策略，超长时会截断或触发临时文件写入。常见错误现象包括：
- 查询突然卡住几秒，
SHOW PROCESSLIST显示Copying to tmp table on disk -
EXPLAIN中Extra字段出现Using temporary; Using filesort - PostgreSQL 的
EXPLAIN ANALYZE显示HashAgg后跟大量External sort
替代方案比优化 GROUP BY 更有效
当分组维度高基数（如按毫秒时间戳分组）或结果集极大时，硬优化索引收益有限。此时应考虑：
- 提前物化：用
MATERIALIZED VIEW（PostgreSQL）或汇总表（MySQL）每日/每小时预计算 - 改用窗口函数：如需每个分组内取最新一条，
ROW_NUMBER() OVER (PARTITION BY x ORDER BY y DESC)常比GROUP BY + JOIN快得多 - 下推到应用层聚合：对实时性要求不高的报表，用 ClickHouse 或 Druid 替代 OLTP 数据库做分组
最容易被忽略的一点：GROUP BY 的性能拐点往往不在数据量，而在分组后结果集大小——哪怕原表只有 10 万行，若分出 50 万组，内存就扛不住。先 SELECT COUNT(DISTINCT ...) 看分组粒度，比盲目建索引管用。
