using temporary表明group by未走索引，mysql需将匹配行载入临时表硬分组；关键看extra列而非key列，复合索引须按where→group by→select顺序创建，且避免在group by中使用函数。
EXPLAIN里出现Using temporary就说明GROUP BY没走索引
这不是警告，是确诊书：MySQL被迫把所有匹配行读进内存或磁盘临时表，再硬分组。哪怕表只有80万行，一见Using temporary或Using filesort，查询大概率从200ms跳到秒级甚至更久。
关键不是看key列有没有索引名，而是盯Extra列——哪怕key显示用了索引，Extra里有Using temporary，说明索引根本没帮上分组的忙。
-
type是ALL或index（而非ref/range），基本等于索引失效 -
key_len异常大（比如VARCHAR(255)字段只查前10个字符，但key_len显示765），说明索引定义和实际查询不匹配 - 别只检查
WHERE有没有走索引——GROUP BY字段没被覆盖，照样触发临时表
复合索引必须按WHERE → GROUP BY → SELECT顺序建
不是把字段堆进CREATE INDEX就行。MySQL的B+树只在“最左前缀匹配”且能按顺序输出分组键时，才支持松散索引扫描（Loose Index Scan）——这才是毫秒级的关键。
假设语句是：SELECT user_id, COUNT(*) FROM orders WHERE status = 1 AND created_at > '2024-01-01' GROUP BY user_id, product_type;
- 过滤字段
status区分度高，放最左 -
created_at是范围条件，放中间 - 分组字段
user_id、product_type紧随其后 → 索引应为INDEX(status, created_at, user_id, product_type) - 如果还要
SELECT MAX(amount)，把amount加到索引末尾，形成覆盖索引，避免回表 - 千万别写成
INDEX(user_id, product_type, status)——WHERE条件无法利用最左前缀，索引直接废掉
别在GROUP BY里用函数，DATE(created_at)等于自废武功
函数会让索引完全失效，MySQL只能全表扫描再逐行计算。不是“可能慢”，是“必然慢”，且无法通过调参绕过。
错误写法：GROUP BY DATE(created_at)；正确解法分两种场景：
- 高频按天统计：加冗余字段
created_date DATE，建索引INDEX(created_date, user_id)，查询改用WHERE created_date BETWEEN ... GROUP BY created_date - 低频灵活查询：用范围条件缩小数据量，例如
WHERE created_at >= '2024-06-01' AND created_at ，至少先砍掉90%数据再分组 - MySQL 5.7不支持函数索引，别指望
INDEX(DATE(created_at))能生效
千万级以后，物化中间结果比死磕单条SQL更靠谱
索引能加速筛选和分组过程，但改变不了“必须读取所有匹配行”的本质。比如统计某天全部订单金额总和，即使created_at有索引，MySQL仍要遍历当天全部百万行去累加amount。
真正有效的优化是预计算：
- 对亿级表聚合，仅靠索引无法解决性能断崖问题
- 必须结合预聚合（如定时写入汇总表）、分区表（按时间缩小扫描范围）或物化视图（自动维护聚合结果）
- 否则单次扫描百万行将导致性能持续恶化
最容易被忽略的是：业务是否真的需要实时聚合结果？很多所谓“实时报表”，其实容忍分钟级延迟——这时用定时任务+汇总表，比任何SQL调优都来得干脆。
