MySQL 使用临时表执行 GROUP BY 的根本原因是无法“边扫边分组”，必须先获取所有满足 WHERE 条件的行再归堆统计；只有当索引满足松散索引扫描（如 BTREE、最左前缀匹配、无函数操作等）时才能避免临时表，EXPLAIN 中出现 Using index for group-by 才表示成功。
GROUP BY 为什么总显示 Using temporary
根本不是 GROUP BY 本身要建表，而是 MySQL 没法「边扫边分组」——它需要先拿到所有满足 WHERE 条件的行，再按分组字段归堆、统计。只要索引不能让数据天然按 GROUP BY 字段顺序排列，就只能走临时表。
常见触发点包括：
• GROUP BY 字段没索引，或索引类型不是 BTREE（比如 HASH）
• 索引存在，但 GROUP BY 字段不是联合索引的最左前缀，例如索引是 (status, user_id)，却写 GROUP BY user_id
• WHERE 用了范围条件（如 created_at > '2025-01-01'），导致索引无法覆盖分组顺序
• SELECT 中混了非分组、非聚合字段，比如 SELECT name, COUNT(*) FROM t GROUP BY dept_id，MySQL 5.7+ 默认拒绝或强制建临时表
松散索引扫描（Loose Index Scan）才是跳过临时表的关键
MySQL 能跳过临时表的唯一可靠路径，是走「松散索引扫描」：只读索引 B+ 树里每个分组值第一次出现的位置，不回表、不全扫。这要求非常严格：
• 索引必须是 BTREE 类型
• GROUP BY 字段必须是联合索引的**最左前缀**，且顺序完全一致，例如 GROUP BY a, b 需要索引 (a, b)，(b, a) 不行
• 如果有 WHERE 条件，等值过滤字段应放在索引最左侧，例如 WHERE status = 'active' GROUP BY user_id，索引应为 (status, user_id)
• 不能对 GROUP BY 字段做函数或表达式操作，GROUP BY YEAR(create_time) 直接废掉所有索引
• EXPLAIN 的 Extra 列必须显示 Using index for group-by，出现 Using temporary 就说明失败了
tmp_table_size 和 sort_buffer_size 完全不是一回事
很多人一看到 Using temporary 就去调 sort_buffer_size，这是典型误判。这个参数只影响排序操作（比如 ORDER BY 或某些带排序的 GROUP BY），和临时表内存/磁盘切换毫无关系。
真正控制临时表落不落盘的是这两个参数的**较小值**：
• tmp_table_size
• max_heap_table_size
默认都是 16MB（16777216 字节）。一旦分组结果集预估大小超过该值，就会从 MEMORY 引擎切到磁盘（InnoDB 或 MyISAM），性能断崖下跌。
如果确认必须走临时表（比如分组维度极高、无法加索引），才考虑同步调大这两个值，并确保它们相等；否则调得再高也白搭——MySQL 只认小的那个。
SELECT * 或多列混用会悄悄放大临时表体积
临时表不是只存 GROUP BY 字段和聚合结果。如果你写 SELECT *, COUNT(*) FROM t GROUP BY user_id，MySQL 会把整行数据都塞进临时表，哪怕最后只返回几列。这极大加快内存溢出速度。
更隐蔽的问题是：即使你只写 SELECT user_id, COUNT(*)，但如果 user_id 不是主键或唯一键，且没被索引覆盖，MySQL 仍可能因无法确定行归属而回表取全量数据，间接撑大临时表。
实操建议：
• 只查明确需要的字段，避免 *
• 对高频 GROUP BY 字段，优先建覆盖索引，例如 (user_id, status, created_at) 支持 SELECT user_id, COUNT(*), MAX(created_at) FROM t WHERE status = ? GROUP BY user_id
• 若业务真要“每组取最新一条的 title”，别硬写 SELECT title, COUNT(*)，改用 ANY_VALUE(title) + 确保 title 在索引中（如 (user_id, title)）
临时表逻辑依赖索引结构、字段可空性、SQL 模式（如 ONLY_FULL_GROUP_BY）、甚至 MySQL 版本行为差异。盯着一个参数调，不如先看 EXPLAIN 的 Extra 到底在报什么。
