GROUP BY 查询慢主因是未走索引导致Using temporary和Using filesort；EXPLAIN中type为ALL/index、key为NULL、Extra含该提示即失效；复合索引须按WHERE等值字段→GROUP BY字段→SELECT非聚合字段顺序创建，且避免函数/隐式转换。
GROUP BY 查询慢，八成是因为触发了 Using temporary 和 Using filesort —— 这不是数据量大才出的问题，而是索引没对上就必然发生。
怎么一眼看出 GROUP BY 没走索引？
执行 EXPLAIN FORMAT=TRADITIONAL SELECT ... GROUP BY ...，重点盯紧三处：
-
type是ALL或index（而非range/ref）→ 扫描行数失控 -
key列为NULL→ 完全没用上索引 -
Extra出现Using temporary; Using filesort→ 已掉进性能深坑
只要这三项中任一出现，说明 MySQL 正在内存或磁盘里建临时表、再排序分组，而不是靠 B+ 树天然有序性直接聚合。
复合索引字段顺序为什么不能乱？
MySQL 只能利用索引的“最左前缀”做等值过滤和范围扫描，而 GROUP BY 要求分组字段在索引中连续且顺序一致。比如查询：
SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY user_id;
正确索引是 INDEX(status, user_id)，不是 INDEX(user_id, status)。原因：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
status = 'paid'是等值条件，放最左能让索引“切出”一个连续块 - 在这个块内，
user_id天然有序，MySQL 直接按物理顺序扫描就能分组，无需额外排序 - 若反过来建索引，
user_id无序散列，MySQL 只能先把所有status = 'paid'的行捞出来，再扔进临时表排序分组
SELECT 里有非聚合字段，索引还得加它
一旦 SELECT 中出现没被聚合函数包裹的字段（如 SELECT user_id, MAX(amount), name FROM orders GROUP BY user_id），这个 name 就必须进索引，否则会回表——甚至可能让整个索引失效。
- 理想索引：
INDEX(status, user_id, name, amount) - 其中
status支持 WHERE，user_id支持 GROUP BY，name和amount实现覆盖，彻底避免回表 - 如果
name是TEXT类型，不能直接建索引，得用前缀索引（如name(100)），但要注意：前缀索引无法保证精确分组语义，慎用于GROUP BY name
ORDER BY 和 LIMIT 会让索引突然“失灵”
加了 ORDER BY COUNT(*) DESC LIMIT 10 后，即使有完美索引，MySQL 也大概率放弃走索引分组，转而用临时表 + 文件排序。因为索引无法同时满足“按 user_id 分组”和“按 COUNT(*) 排序”两个逻辑。
- 先确认是否真需要数据库层排序：报表类需求常可改用子查询预取 Top N ID，再关联查详情
- 若必须排序且数据量可控，可加
ORDER BY NULL显式关闭排序，避免Using filesort -
SQL_BIG_RESULT不是解药——它只是告诉优化器“结果很大”，强制走磁盘排序，反而更慢
最易被忽略的一点：WHERE 条件里用了函数（如 WHERE DATE(created_at) = '2024-01-01'）或隐式类型转换（如 WHERE user_id = '123'），哪怕索引建得再准，key 也会变 NULL。检查 EXPLAIN 前，先看条件是否“干净”。
