group by字段未走索引必然触发using temporary；需确保联合索引顺序与group by完全一致、避免函数操作、禁用默认排序（order by null）、减少select列以实现覆盖索引。
GROUP BY字段没走索引，必然触发Using temporary
MySQL对大表做GROUP BY时，如果无法利用索引顺序直接分组，就会建临时表——轻则吃内存，重则落盘成MyISAM表，性能断崖下跌。关键不是“有没有索引”，而是“索引能不能被完整命中”。
- 联合索引必须严格匹配
GROUP BY字段顺序，比如GROUP BY user_id, status，就得建INDEX(user_id, status)，单列INDEX(user_id)不够 - WHERE条件字段必须在索引最左，否则整个索引失效；例如有时间范围过滤
WHERE created_at >= '2026-07-01'，索引应为(created_at, user_id, status) - 避免函数操作：
GROUP BY DATE(created_at)无法走普通索引，要么建函数索引，要么改用范围条件+冗余日期字段
SELECT * + GROUP BY = 回表 + 临时表双杀
即使GROUP BY字段有索引，只要写SELECT *，MySQL就不得不回表取所有列，这会破坏覆盖索引能力，大概率触发Using temporary。
- 只查真正需要的列，例如
SELECT user_id, COUNT(*) FROM t GROUP BY user_id，配合INDEX(user_id)就能完全走索引 - 如果还要带
MAX(created_at)这类聚合字段，把created_at加进联合索引尾部，形成覆盖：INDEX(user_id, created_at) - 高基数字符串字段（如
user_email）分组代价极高，优先转成整型ID关联后再分组
ORDER BY NULL不是玄学，是明确禁用排序
很多场景根本不需要结果有序，但MySQL优化器看到GROUP BY就默认准备排序，哪怕你没写ORDER BY。加ORDER BY NULL是唯一能显式关掉这个行为的方式。
-
SELECT user_id, COUNT(*) FROM t GROUP BY user_id ORDER BY NULL—— 这句比不加ORDER BY更可靠 - 如果业务真要排序，
ORDER BY字段顺序、方向必须和GROUP BY完全一致，且索引也得同步支持混合方向（MySQL 8.0+才支持ASC/DESC混用） - 别信“加了索引就一定不临时表”，执行计划里出现
Using temporary就是铁证，立刻检查EXPLAIN FORMAT=TREE输出
临时表不是不能用，而是不能“裸用”
当聚合逻辑复杂到无法单条SQL表达时，临时表仍是必要手段——但必须控制它的开销边界。
- 建表时显式定义字段类型和长度，别用
SELECT * INTO #tmp，避免隐式推断导致过度分配 - 大数据量插入后立即建索引，且索引必须在
INSERT之前创建，否则优化器看不到统计信息，后续JOIN全走错路 - 存储过程里务必
DROP TABLE #tmp，尤其分支逻辑中，残留临时表会影响下一次执行计划
真正卡住性能的，往往不是数据量本身，而是索引没对齐分组字段顺序、SELECT列过多、或者忘了ORDER BY NULL这行看似多余的指令。
