using temporary表示mysql放弃索引分组，改用临时表，数据量超十万时性能断崖下降；常见于having过滤、select非分组字段、相关子查询、隐式排序及索引不匹配等情况。
EXPLAIN里出现Using temporary说明什么
这表示MySQL放弃了索引的天然分组能力，改用全表扫描 + 内存或磁盘临时表来完成分组。不是“慢一点”，而是数据量一过十万，响应时间就断崖式上升。
关键判断依据就是EXPLAIN输出中Extra列是否含Using temporary——这不是警告，是明确信号：当前执行计划必须走临时表。
常见伴随现象：Using filesort往往同时出现，说明连排序都保不住；type=ALL或key=NULL则基本坐实索引没生效。
哪些SQL写法会悄悄触发临时表
很多优化失败，其实卡在SQL本身，和索引无关。
-
HAVING做过滤：比如HAVING status = 'completed'，MySQL必须先分组再过滤，数据已膨胀；应移到WHERE里 -
SELECT *或选了非分组、非聚合字段：如SELECT user_id, name, COUNT(*) FROM t GROUP BY user_id，哪怕name只多一个字段，也可能导致回表，让优化器放弃索引分组 - 相关子查询：如
SELECT u.id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id GROUP BY o.user_id)，几乎必然触发Using temporary - 隐式排序需求：MySQL 5.7 默认对
GROUP BY结果隐式排序，哪怕你不需要；加ORDER BY NULL能砍掉这个开销
索引建不对，等于没建
不是“加个索引就行”，而是索引必须严格匹配查询结构：等值条件放最左，分组字段紧随其后，非聚合字段尽可能覆盖。
例如：
- 单字段分组
GROUP BY user_id，但带WHERE status = 'active'→ 建(status, user_id)，不是(user_id) - 多字段分组
GROUP BY user_id, DATE(created_at)→ MySQL 5.7不支持函数索引，得新增生成列created_date DATE AS (DATE(created_at))，再建(user_id, created_date) -
GROUP BY a, b ORDER BY a, b→ 一个(a, b)索引可同时服务两者；但若ORDER BY a DESC, b ASC，5.7不支持混合方向，必然退化
索引顺序错位也白搭：比如GROUP BY a, b却只建了(b, a)或(a)单列索引，照样触发临时表。
类型隐式转换和函数操作是隐形杀手
看着用了索引，其实根本没走。
- 对字段做函数：如
GROUP BY DATE(created_at)，哪怕created_at有索引也失效；改用范围条件+索引，如WHERE created_at >= '2024-01-01' AND created_at - 类型不一致：如
user_id是VARCHAR，但WHERE user_id = 123传了整数，MySQL会做隐式转换，导致索引失效 + 临时表 - JOIN条件字段类型不匹配：同样引发索引失效，间接让
GROUP BY无法复用索引
真正难缠的从来不是大SQL，而是那些看起来“应该能走索引”的小细节——它们藏在类型、函数、顺序和模式配置里，不查EXPLAIN根本发现不了。
