GROUP BY触发Using temporary的根本原因是索引未按最左前缀顺序覆盖GROUP BY字段，导致MySQL无法流式分组，必须建临时表归并；需构建WHERE等值字段+GROUP BY字段严格顺序的联合索引，并避免函数包裹或顺序错配。
为什么GROUP BY总触发Using temporary？
不是你写错了SQL，而是MySQL发现GROUP BY字段没被索引“顺序覆盖”，只能建内存或磁盘临时表来归并。关键信号是EXPLAIN里出现Using temporary，尤其和Using filesort一起出现时，说明既没走索引排序，又被迫落盘。
- 索引必须是联合索引，且列顺序与
GROUP BY完全一致，比如GROUP BY user_id, status就得配INDEX(user_id, status)，单列索引无效 -
WHERE条件字段必须在索引最左，否则整个索引失效；例如有时间范围过滤WHERE created_at > '2026-01-01'，索引应设为(created_at, user_id, status) - 避免对分组字段做函数操作，
GROUP BY DATE(created_at)无法用普通索引，得建函数索引或冗余日期字段
ORDER BY NULL真能跳过排序开销？
能，而且很有效——只要你根本不需要结果有序。MySQL默认会在GROUP BY后隐式加ORDER BY，哪怕你没写，只要优化器认为可能需要就预留排序逻辑。加ORDER BY NULL是明确告诉它：“别排，我只要聚合值”。
- 这个技巧只适用于业务不关心输出顺序的场景，比如统计报表后台计算、中间指标生成
- 它不解决
Using temporary本身，但能避免双重开销：既建临时表又做文件排序 - 注意不要和
ORDER BY混用，写了ORDER BY NULL再写别的排序会冲突，直接报错
临时表真比CTE或子查询快？
不一定。临时表只有在“同一中间结果被多次引用”或“需加索引加速后续JOIN”时才有优势；其他情况大概率更慢。
- 单次使用的中间聚合，优先用CTE或派生表，避免物理创建/销毁开销
- 如果中间结果要JOIN大表，且行数超500，给临时表建索引确实有用，但得手动执行
CREATE INDEX，不能依赖自动 - 在存储过程里循环中反复
CREATE TEMPORARY TABLE，比TRUNCATE + INSERT慢得多——DDL锁会卡住并发
怎么确认是不是磁盘临时表拖慢了查询？
看Created_tmp_disk_tables这个状态值，而不是只盯着有没有临时表。
- 执行
SHOW STATUS LIKE 'Created_tmp%'，算出Created_tmp_disk_tables / Created_tmp_tables占比；超过5%就得调优 - 检查
tmp_table_size和max_heap_table_size是否设为相等，且足够大（比如256MB），否则调大tmp_table_size也没用 - MySQL 8.0+建议启用
internal_tmp_mem_storage_engine=TempTable，它比传统MEMORY引擎更省内存、支持BLOB
WHERE位置和函数陷阱。 
