GROUP BY触发Using temporary的直接信号是EXPLAIN中Extra列出现Using temporary，表明MySQL被迫建临时表；根本原因是索引未按WHERE→GROUP BY→聚合列顺序严格覆盖，导致无法流式扫描分组。
GROUP BY触发Using temporary的直接信号是什么
执行EXPLAIN后，Extra列出现Using temporary——这就是MySQL被迫建临时表的铁证。不是数据量大才出问题，哪怕只有几万行，只要GROUP BY字段没走索引，就大概率触发。更危险的是，一旦tmp_table_size不够，临时表会立刻落盘，查询耗时从毫秒跳到秒级。
复合索引必须按WHERE → GROUP BY → 聚合列顺序组织
索引不是随便堆字段就行，顺序错一个，整个优化就失效。核心逻辑是：MySQL只能用索引的“最左前缀”做快速定位和有序遍历。
- 如果查询带
WHERE status = 'paid'且GROUP BY user_id，索引得是(status, user_id)，不能反过来 - 如果还要
SUM(amount)，就得补上amount：索引为(status, user_id, amount)，构成覆盖索引 -
COUNT(*)不依赖具体值，所以(user_id)单列索引对纯计数分组就够用；但AVG(salary)或MAX(created_at)就必须把对应字段放进索引末尾
ORDER BY混用时，索引顺序极易翻车
当GROUP BY user_id ORDER BY COUNT(*) DESC时，COUNT(*)是聚合结果，无法被索引预排序——MySQL只能先分组、再排序，必然出现Using temporary; Using filesort。
- 唯一能避免的办法：让
ORDER BY字段也出现在索引里，且顺序与GROUP BY一致，比如GROUP BY user_id ORDER BY user_id DESC可走(user_id)索引 - 如果业务真要按聚合值排序（如“销量Top 10用户”），别硬扛SQL层，改用应用层排序，或提前把聚合结果写入统计表并加索引
- MySQL 8.0+支持降序索引，但仅对
ORDER BY字段有效，对GROUP BY无额外帮助
松散索引扫描（Loose Index Scan）怎么才算真正生效
不是建了索引就自动启用松散扫描，必须同时满足三个条件：
- 索引类型是
BTREE（HASH索引完全无效） -
GROUP BY字段是联合索引的最左前缀，例如索引(user_id, created_at)支持GROUP BY user_id，但不支持GROUP BY created_at -
EXPLAIN的Extra列显示Using index for group-by，而不是Using temporary
最容易被忽略的一点：只要SELECT里混了非分组、非聚合字段（比如SELECT name, COUNT(*) FROM t GROUP BY dept_id），哪怕索引完美匹配，MySQL也会退回到临时表模式——要么删掉name，要么用ANY_VALUE(name)显式声明语义，并确保name在索引中。
