ORDER BY与GROUP BY字段不匹配、顺序不一致或未被同一联合索引严格覆盖时，MySQL无法流式分组和排序，必然触发Using temporary；根治方法是按WHERE=等值条件+GROUP BY字段+ORDER BY字段（顺序/方向一致）构建最左前缀覆盖索引。
为什么 ORDER BY + GROUP BY 容易触发 Using Temporary
当查询同时含 ORDER BY 和 GROUP BY，且字段不完全匹配、顺序不一致或没被同一索引覆盖时，MySQL 无法复用索引排序能力，必须在内存或磁盘建临时表做二次排序或去重。典型现象是 EXPLAIN 输出中 Extra 列出现 Using temporary; Using filesort。
组合索引字段顺序必须严格匹配查询需求
索引不是“包含字段就行”，而是按定义顺序逐级生效。若查询写成 GROUP BY a, b ORDER BY b, a，即使建了 INDEX(a,b) 也无效——因为 ORDER BY b, a 不符合最左前缀，且与索引顺序冲突。
实操建议：
- 先确定查询中
GROUP BY和ORDER BY的字段及顺序，合并为一个逻辑序列（如GROUP BY user_id, status ORDER BY status, created_at→ 索引应为(user_id, status, created_at)） -
GROUP BY字段必须是索引最左连续前缀；ORDER BY后续字段必须紧接其后，且方向一致（全部ASC或全部DESC，MySQL 8.0+ 才支持混合方向索引） - 避免在索引中混入
WHERE条件字段（如WHERE deleted=0）后接GROUP BY字段——除非该条件是高选择性且常驻过滤，否则会打断排序连续性
用 EXPLAIN FORMAT=TREE 验证是否真正免临时表
EXPLAIN 的传统格式容易误判：即使显示 Using index，也可能仍用临时表。必须用 MySQL 8.0+ 的树形执行计划确认实际行为。
示例对比：
EXPLAIN FORMAT=TREE SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY user_id ORDER BY user_id DESC;
若输出中不含 "using_temporary_table": true，且有 "sort_direction": "backward"，说明走索引完成排序，未建临时表。
常见陷阱：
-
SQL_BUFFER_RESULT会强制生成临时表，即使索引完备也要检查是否被无意启用 - 使用
DISTINCT替代GROUP BY时，索引设计逻辑不同，不能直接套用 - 字符集或校对规则不一致（如
utf8mb4_0900_as_csvsutf8mb4_general_ci）会导致索引无法用于排序，哪怕字段名和顺序都对
聚合字段本身不能出现在组合索引中间位置
如果 SELECT 中有非分组字段（如 SELECT user_id, MAX(amount), city），而 city 不在 GROUP BY 中，MySQL 会报错（ONLY_FULL_GROUP_BY 模式下）或返回不确定值——此时无论怎么建索引，都绕不开临时表来协调语义。
正确做法是：
- 确保
SELECT列中所有非聚合字段，都完整出现在GROUP BY子句中，并作为索引最左前缀 - 聚合函数如
MAX(created_at)对应的字段，可放在索引末尾，但不能插在GROUP BY字段中间（例如(user_id, created_at, status)无法支持GROUP BY user_id, status） - 覆盖索引要包含所有
SELECT字段，否则回表会削弱排序效率，甚至让优化器放弃使用该索引
Using Temporary 就会回来。 
