MySQL执行GROUP BY时，只要无法用索引直接完成分组逻辑就会触发内部临时表；常见原因包括GROUP BY字段无索引或不满足最左前缀、WHERE含范围条件、分组字段为表达式、使用HAVING过滤等。
GROUP BY 什么时候触发内部临时表
MySQL 执行 GROUP BY 时，**只要无法用索引直接完成分组逻辑，就会创建内部临时表**——这不是可选项，是优化器自动决定的执行路径。常见触发场景包括：
• GROUP BY 字段无索引，或索引不满足最左前缀（如索引是 (a, b)，却按 b 分组）
• WHERE 条件含范围查询（如 created_at > '2024-01-01'），破坏索引有序性
• 分组字段是表达式（如 user_id % 10、UPPER(name)），无法走索引
• 使用了 HAVING 过滤聚合结果，且该条件无法下推到扫描阶段
内存临时表 vs 磁盘临时表怎么选
MySQL 默认先尝试用内存临时表，但是否真能留在内存里，取决于两个配置项的**较小值**：tmp_table_size 和 max_heap_table_size（默认都是 16MB）。只要中间结果（分组键 + 聚合值 + 可能的排序字段）总大小超过这个阈值，就会自动落盘，引擎默认为 InnoDB（不是 MyISAM）。
• 查当前阈值：SHOW GLOBAL VARIABLES LIKE 'tmp_table_size';
• 判断是否已落盘：SHOW STATUS LIKE 'Created_tmp_disk_tables';，数值增加说明有磁盘临时表产生
• 注意：即使 EXPLAIN 显示 Using temporary，也不代表一定慢；小数据量下全程走内存，开销很低
为什么 EXPLAIN 里常带 Using filesort
Using temporary 后紧跟着 Using filesort，说明 MySQL 不仅建了临时表，还在临时表上额外做了一次排序——这几乎总是因为**没加 ORDER BY NULL**。
• 默认行为：MySQL 对 GROUP BY 结果会按分组字段再排一次序，哪怕你没写 ORDER BY
• 解决方法：显式加上 ORDER BY NULL，例如：SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY NULL;
• 如果业务真需要排序，优先建联合索引覆盖 GROUP BY + ORDER BY 字段（如 INDEX(user_id, created_at)），避免二次排序
松散索引扫描能完全绕过临时表
满足松散索引扫描（Loose Index Scan）条件时，MySQL 可跳过临时表，直接顺序扫描索引完成分组。核心限制很严格：
• 必须单表查询
• GROUP BY 字段必须是索引的**最左前缀**（如索引 (user_id, created_at)，只按 user_id 分组可以，按 created_at 就不行）
• 不能有范围 WHERE 条件干扰索引连续性（等值条件 OK，>/BETWEEN 不行）
• SELECT 中若含 MIN()/MAX()，其参数列必须在索引中且紧跟在 GROUP BY 字段之后
• EXPLAIN 中对应显示 Using index for group-by，而非 Using temporary
真正容易被忽略的是：松散索引扫描对索引结构和查询写法极其敏感，差一个等号、多一个函数，就退回紧凑索引扫描甚至全表+临时表。线上慢查调优时，别只盯着 tmp_table_size 调大，先确认索引是否真被用于分组逻辑。
