GROUP BY 变慢几乎总是因触发临时表和文件排序；根本原因是未用最左前缀联合索引覆盖WHERE、GROUP BY及SELECT非聚合列，导致MySQL无法有序扫描而被迫建临时表并额外排序。
GROUP BY 变慢，几乎总是因为 MySQL 不得不创建临时表并执行文件排序——这不是配置问题，是执行路径失控的明确信号。
为什么 GROUP BY 会触发 Using temporary 和 Using filesort
MySQL 默认对 GROUP BY 的实现依赖排序或哈希聚合。当它发现无法利用索引直接按分组键顺序读取数据时，就会把中间结果写入内存（tmp_table_size 内）或磁盘临时表，再做排序和分组。一旦数据量超出内存阈值，就会落到磁盘，I/O 暴涨；而 Using filesort 表示它还得额外跑一遍排序流程，哪怕你根本不需要结果有序。
- 常见诱因包括：
GROUP BY字段没索引、索引顺序与GROUP BY字段顺序不一致、SELECT中包含非聚合列且未被索引覆盖 -
WHERE条件含范围查询（如created_at > '2024-01-01'）且放在联合索引中间位置，会截断索引有效长度，导致后续分组字段无法被有序扫描 - 隐式类型转换（如
user_id = '123'对比BIGINT字段）会让索引失效，整个扫描退化为全表
如何用 EXPLAIN 快速确认是不是临时表/排序问题
执行 EXPLAIN 后紧盯 Extra 列：
- 出现
Using temporary：说明 MySQL 正在建临时表存分组中间态，无论内存还是磁盘，都已偏离高效路径 - 出现
Using filesort：说明它无法靠索引物理顺序完成分组，必须额外排序——即使你没写ORDER BY，GROUP BY 本身隐含排序语义 -
key显示用了索引，但Extra仍有上述两项：说明索引存在，但没被“正确使用”，比如只覆盖了WHERE条件，没覆盖分组逻辑
临时表和排序不是“能忍就忍”的问题，而是性能断崖点
临时表大小受 tmp_table_size 和 max_heap_table_size 共同限制。一旦突破，MySQL 就会把临时表刷到磁盘（/tmp 或 tmpdir），此时每万行分组可能带来数百毫秒延迟。更麻烦的是，Using filesort 在大数据集上往往伴随大量随机 I/O，SSD 都扛不住。
- 别指望调大
tmp_table_size解决根本问题——它只是掩盖症状，数据量再翻一倍照样崩 -
ORDER BY NULL能干掉隐式排序，但仅对Using filesort有效；如果Using temporary还在，分组逻辑本身仍低效 - 真正可靠的解法是让 MySQL “不用建临时表”：通过最左前缀联合索引，使数据在磁盘上天然按
GROUP BY字段物理有序
最容易被忽略的一点：即使 GROUP BY 字段上了单列索引，只要查询里带 WHERE 条件或 SELECT 其他字段，这个单列索引大概率就废了——优化器不会自动拼接多个索引，必须显式建联合索引覆盖完整访问链路。
