explain出现using temporary说明索引无法支持流式分组，必须调整索引结构：group by字段顺序须与索引最左前缀严格一致，where等值条件前置，避免函数、隐式转换及非聚合列导致覆盖索引失效。
只要 EXPLAIN 的 Extra 列出现 Using temporary，就说明 MySQL 没法靠索引流式分组，已经掉进临时表陷阱——这不是参数能救的，得从索引结构和查询写法上动刀。
GROUP BY字段顺序必须和索引字段顺序完全一致
MySQL 的松散索引扫描（Loose Index Scan）只认顺序，不认集合。哪怕你建了 INDEX(user_id, status)，但查询是 GROUP BY status, user_id，索引就废了。
- 正确匹配：查询
GROUP BY a, b, c→ 索引必须是(a, b, c)，不能是(b, a, c)或(a, c, b) - WHERE 条件字段要插在最左：如果有
WHERE dept = 'tech' AND salary > 5000，再GROUP BY team, role，索引就得是(dept, salary, team, role)—— 范围条件salary > 5000必须放在等值条件之后、分组字段之前 - 高基数字符串字段（如
email）直接进GROUP BY，基本等于放弃索引优化；优先 JOIN 到整型 ID 再分组
别让SELECT *或非聚合列破坏覆盖索引
SELECT * 和 SELECT name, COUNT(*) 这类写法，会让 MySQL 不得不回表取数据，覆盖索引失效，优化器大概率弃用你辛辛苦苦建的索引，转头去建临时表。
- 只查真正需要的字段：比如
SELECT user_id, COUNT(*) FROM t GROUP BY user_id，配合INDEX(user_id)就能走Using index - 要带聚合字段？把它们加到索引末尾：比如还要
MAX(created_at)，索引就该是INDEX(user_id, created_at) - 如果用了
ONLY_FULL_GROUP_BY（MySQL 5.7+ 默认开启），SELECT name, COUNT(*)会直接报错；即使关了，也可能触发临时表——不是语法问题，是语义不确定性逼 MySQL 备份全量行
函数、表达式、隐式排序都会绕过索引
任何对 GROUP BY 字段的加工，都在告诉 MySQL：“别找索引了，老老实实扫表吧”。这不是“可能慢”，是“必然触发 Using temporary”。
- 禁止写
GROUP BY DATE(created_at)：普通索引对函数无效；MySQL 5.7 不支持函数索引，别试 - 替代方案：加冗余字段
created_date DATE，建索引INDEX(created_date, user_id)，查询改用WHERE created_date = '2026-09-01' GROUP BY created_date - 必须加
ORDER BY NULL：MySQL 默认对GROUP BY结果做升序排序，哪怕你没写ORDER BY；不加这句，Extra很可能同时出现Using temporary和Using filesort - 如果业务真要排序，
ORDER BY字段顺序、方向必须和GROUP BY完全一致，且索引也要支持（MySQL 8.0+ 才支持混合 ASC/DESC）
执行计划里 Using temporary 是铁证，别信“应该走了索引”
别只看 key 列显示用了哪个索引，重点盯 Extra 列。哪怕 key 显示 idx_status_uid，只要 Extra 有 Using temporary，说明这个索引对分组毫无帮助。
- 用
EXPLAIN FORMAT=TREE查看更细的执行路径，确认是否启用 Loose Index Scan -
type是ALL或index（而非ref/range），基本等于索引白建 -
key_len异常大（比如VARCHAR(255)字段只用前 10 字符，但key_len显示 765），说明索引定义和实际查询不匹配 - 临时表不是不能用，但一旦看到
Coping to tmp table on disk出现在SHOW PROCESSLIST里，说明已落到磁盘，I/O 开销已失控
真正卡住性能的，往往不是数据量，而是分组维度本身——比如直接按 user_id + ip_address + ua_string 分组，这种组合基数太高，索引根本压不住。这时候与其死磕单条 SQL，不如提前 JOIN 降维，或者用子查询预聚合。索引只是工具，理解数据分布和查询意图才是关键。
