临时表和排序开销过大源于索引未覆盖where条件、group by字段及select非聚合列；需建严格顺序的联合索引，避免select *、范围条件中断索引、orm隐式排序等陷阱。
临时表和排序开销过大，几乎总是因为 MySQL 没法靠索引直接完成分组——它不是“慢”，而是被迫换了一条低效路径：先把数据全捞出来，再建表、再排序、再归并。
EXPLAIN里出现Using temporary就说明索引没对上
看到Using temporary别急着调tmp_table_size，先确认索引是否覆盖了三件事：WHERE条件字段、GROUP BY字段、SELECT中非聚合列。比如：
-
SELECT user_id, COUNT(*) FROM orders WHERE status = 'shipped' GROUP BY user_id，必须建INDEX(status, user_id)，而不是INDEX(user_id)或INDEX(status) - 如果还带
MAX(created_at)，得把created_at加到索引末尾：INDEX(status, user_id, created_at)，否则照样回表、触发临时表 - 索引顺序必须严格匹配
GROUP BY字段顺序：GROUP BY a, b→ 索引必须是(a, b)，(b, a)无效
ORDER BY NULL只能干掉Using filesort，不能消灭Using temporary
ORDER BY NULL的作用很具体：告诉优化器“我不需要结果有序”，从而跳过隐式排序步骤。但它不解决分组逻辑本身低效的问题。
- 如果
EXPLAIN里同时有Using temporary和Using filesort，加ORDER BY NULL只会去掉后者，前者还在吃内存 - 真正该检查的是：WHERE里的范围条件（如
created_at > '2026-01-01'）有没有放在联合索引中间？一旦出现，后续字段索引失效，GROUP BY就失去依托 - 某些ORM或客户端会偷偷加排序，导致本地快、线上慢，别被
ORDER BY NULL的表面效果骗过去
SELECT * + GROUP BY = 回表 + 临时表双杀
写SELECT *在聚合语句里是最常见的性能陷阱之一。MySQL无法用索引覆盖所有列，只能回表取数据，这直接破坏覆盖索引能力。
- 哪怕
GROUP BY user_id有单列索引，只要写SELECT *，优化器大概率放弃走索引，改用全表扫描+临时表 - 正确做法是只查真正需要的列：
SELECT user_id, COUNT(*), MAX(updated_at) FROM t GROUP BY user_id，再配INDEX(user_id, updated_at) - 高基数字符串字段（如
user_email）直接分组代价极高，优先关联整型user_id后再分组
最容易被忽略的一点：即使你给每个GROUP BY字段都单独建了索引，只要没建对联合索引的顺序和覆盖范围，MySQL依然会建临时表——执行计划里的Using temporary不会说谎，但很多人只看key列是否非NULL，就以为索引生效了。
