GROUP BY性能差主因是MySQL被迫使用临时表和文件排序，判断依据为EXPLAIN中type非ALL/index且Extra无Using temporary/Using filesort。

GROUP BY没走索引？先看EXPLAIN里的type和Extra

执行慢不是因为GROUP BY语法本身，而是MySQL被迫用临时表+文件排序。关键判断依据只有两个：type不能是ALL或index，Extra里不能出现Using temporary或Using filesort。一旦出现，说明索引没对上，或者查询结构破坏了索引可用性。

常见误判：给user_id建了单列索引，但查询带WHERE status = 'paid'，结果还是全表扫描——因为过滤和分组没共用一个索引。

• 必须用EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN ANALYZE（PostgreSQL）验证，不能凭感觉
• 如果rows显示扫描行数远大于实际分组数（比如扫500万行只出200个分组），说明WHERE没有效过滤
• NULL值会影响索引选择，加WHERE col IS NOT NULL有时能激活索引

索引字段顺序错了，再宽的索引也没用

联合索引不是“包含所有字段”就行，顺序决定它能不能被GROUP BY复用。核心规则就一条：WHERE条件字段最左，GROUP BY字段紧随其后，SELECT中非聚合字段放末尾。

例如查询：SELECT user_id, MAX(created_at), SUM(amount) FROM orders WHERE status = 'paid' GROUP BY user_id，理想索引是(status, user_id, created_at, amount)。

• 错序示例：(user_id, status)对这个查询基本无效——MySQL无法先按user_id排序再去过滤status
• 如果还带ORDER BY COUNT(*) DESC LIMIT 10，索引再好也救不了；此时Using filesort是必然的，得换预聚合方案
• 别把remark、content这类大字段塞进索引，写入开销和缓存压力会陡增

GROUP BY字段上用了函数？索引直接失效

GROUP BY DATE(create_time)、GROUP BY UPPER(name)、WHERE id = '123'（id是INT）——这些写法会让索引彻底作废，哪怕字段本身有索引。

替代方案不是“换个函数”，而是前置计算或结构改造：

• 用生成列：ALTER TABLE logs ADD COLUMN create_date DATE AS (DATE(create_time)) STORED，再对create_date建索引
• 时间范围查询优先用区间：WHERE create_time >= '2024-01-01' AND create_time ，再GROUP BY create_date
• 类型不一致时显式转换：WHERE id = CAST('123' AS UNSIGNED)，比隐式转换更可控

为什么加了ORDER BY NULL还是慢？可能漏了聚合字段覆盖

ORDER BY NULL只能禁用结果集排序，但解决不了回表和临时表问题。真正卡住的，往往是SELECT里那些非分组字段没被索引覆盖。

比如SELECT dept_id, AVG(salary), MAX(hire_date) FROM emp GROUP BY dept_id，只建(dept_id)索引没用——AVG()和MAX()需要读取每组所有salary和hire_date值，必须让它们也进索引。

• 索引应为(dept_id, salary, hire_date)，且salary和hire_date在B+树里天然有序，MAX/MIN可快速定位
• COUNT(*)和COUNT(非空列)在覆盖索引下性能几乎一样；但COUNT(col)（col允许NULL）仍需逐行判空，无法完全跳过数据页
• 如果业务只要Top 10分组，别硬扛全量分组，改用窗口函数或物化汇总表

覆盖索引不是加字段越多越好，而是精准匹配查询链路：WHERE → GROUP BY → SELECT非聚合字段。少一个环节没覆盖，优化就断在那儿。