为什么SQL中使用GROUP BY会导致查询变慢_分析执行计划中的临时表与文件排序-SQL-PHP中文网

GROUP BY变慢主因是执行计划出现Using temporary或Using filesort；前者表明MySQL建临时表存分组结果，后者代表额外排序，均因索引未覆盖过滤+分组+返回字段全链路所致。

为什么sql中使用group by会导致查询变慢_分析执行计划中的临时表与文件排序

GROUP BY 变慢，大概率是因为执行计划里出现了 Using temporary 或 Using filesort —— 这不是警告，是数据库已经放弃走索引、开始硬扛的明确信号。

直接跑 EXPLAIN，盯住 Extra 列：

只要出现 Using temporary，说明 MySQL 正在内存或磁盘上建临时表来存分组中间结果；数据量一过几万行，就很容易溢出到磁盘，I/O 暴涨
出现 Using filesort，代表它得额外对 GROUP BY 字段做一次排序——哪怕你没写 ORDER BY，MySQL 默认也会按分组键排，除非显式加 ORDER BY NULL
key 列显示 NULL 或用了不匹配的索引，type 是 ALL 或 index（全索引扫描），基本等于没走有效路径

根本原因是：索引没覆盖“过滤 + 分组 + 返回字段”整条访问链。常见断点有：

GROUP BY a, b，但索引是 (b, a) 或 (a) 单列 —— 左前缀不匹配，无法利用索引天然有序性
SELECT a, b, SUM(c)，索引只建了 (a, b)，c 得回表查，MySQL 认为不如全扫+临时表聚合更省事
WHERE created_at > '2024-01-01' 是范围查询，放在复合索引中间或开头，会让后续字段失效，GROUP BY user_id 就没法接着用索引顺序
隐式类型转换：比如 user_id 是 BIGINT，但写成 WHERE user_id = '123'，索引直接失效，连带 GROUP BY 失去依托

有用，但只解决表层症状，不治本：

加 ORDER BY NULL 能干掉 Using filesort，前提是执行计划里 Using temporary 已经消失 —— 否则只是少排一次序，临时表还在那儿吃内存
如果 Extra 里同时有 Using temporary 和 Using filesort，删掉 ORDER BY NULL 不会变快；加了也不会变快太多
某些客户端（比如 SQLyog）会偷偷优化掉排序逻辑，导致本地快、服务器慢，别被这种假象骗过去

版本差异直接影响你能不能靠索引绕开临时表：

MySQL 5.7 不支持函数索引，GROUP BY DATE(created_at) 没法直接建索引覆盖；你得先加生成列 created_date，再建索引，否则必走临时表
MySQL 8.0 支持 INDEX (DATE(created_at))，也支持降序索引，比如 (status DESC, category ASC)，能同时满足 GROUP BY status, category 和 ORDER BY status DESC, category，避免双排序
8.0 的 EXPLAIN FORMAT=TREE 能直接看到 “Using index for group-by”，5.7 只能靠 Extra 里没 Using temporary + key 非空来猜