MySQL GROUP BY出现Using temporary是因为无法利用索引顺序分组，必须建临时表处理；需满足BTREE索引、GROUP BY列为最左前缀、WHERE等值条件前置、无函数操作、加ORDER BY NULL等全部条件，才能触发松散索引扫描跳过临时表。
为什么GROUP BY总出现Using temporary
看到EXPLAIN的Extra列里有Using temporary，说明MySQL没走索引分组路径，而是把所有匹配行先塞进内存临时表，再排序、去重、聚合。这不是GROUP BY语法本身的问题，而是它没法“顺着索引顺序读”，导致相同分组值不连续——必须缓存后处理。
建什么索引才能真正跳过临时表
核心是让MySQL能做松散索引扫描（Loose Index Scan），即只读索引里每个分组的“第一个键”，不扫全量行。这要求：
- 索引类型必须是
BTREE（HASH索引完全无效） -
GROUP BY字段必须是联合索引的最左前缀，比如GROUP BY user_id，索引就得是(user_id)或(user_id, created_at)；(status, user_id)对纯GROUP BY user_id就无效 - 如果有
WHERE等值条件（如WHERE status = 'paid'），要把该字段放索引最左，再接分组字段，即(status, user_id) - 避免在
GROUP BY列上用函数，比如GROUP BY YEAR(created_at)会彻底废掉索引 - 用
EXPLAIN确认：Extra显示Using index for group-by才算成功；Using temporary就是失败
SELECT里带非分组字段怎么办
业务常要“每组取最新一条的title”，但SELECT title, COUNT(*) FROM t GROUP BY user_id会触发ONLY_FULL_GROUP_BY错误或强制建临时表。正确解法：
- 如果只需要任意一条，用
ANY_VALUE(title)，并确保title在索引中（比如索引是(user_id, title)） - 如果必须取最新/最大值，且字段紧邻分组列，可用
MAX(created_at)，前提是索引为(user_id, created_at)，且created_at是索引第二列 - 别写
SELECT *——只要多一个没被索引覆盖的列，优化器就可能弃用松散扫描，退回到临时表
ORDER BY NULL不是可选项，是必加项
MySQL 5.7+ 默认对GROUP BY结果隐式按分组字段升序排序，哪怕你没写ORDER BY。这个行为会触发Using filesort，和Using temporary常一起出现。加ORDER BY NULL后，只要索引结构正确，Extra会变为空或仅Using index。不加的话，即使索引完美，排序开销也可能压倒聚合本身。
真正难的不是建索引，而是让索引列顺序、WHERE条件、SELECT字段、ORDER BY逻辑全部对齐——少一个条件，MySQL就放弃松散扫描，乖乖建临时表。
