GROUP BY 查询慢的根本原因是索引未覆盖WHERE过滤、GROUP BY分组和SELECT取值全链路；需按WHERE字段、GROUP BY字段、SELECT非聚合字段顺序创建组合索引，且避免WHERE中使用函数导致索引失效。
GROUP BY 查询慢，是不是索引没覆盖 SELECT 和 WHERE 字段？
绝大多数分组统计慢，根本原因不是 GROUP BY 本身，而是 MySQL 没法用索引完成“过滤 + 分组 + 取值”整条链路，被迫回表或全表扫描。比如：SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY user_id，如果只在 status 上建单列索引，MySQL 查完 status 还得回到聚簇索引捞 user_id，再分组——这很耗。
- 组合索引必须把
WHERE条件字段放最左（如status），这是最硬的规则 -
GROUP BY字段紧随其后（如user_id），这样索引能直接按顺序分组，避免额外排序 - 如果
SELECT里还有其他非聚合字段（比如MAX(created_at)），它们也得加到索引末尾，才能实现“索引覆盖”，彻底避免回表 - 顺序错了就失效：
(user_id, status)对WHERE status = ? GROUP BY user_id几乎没用
为什么 ORDER BY 和 LIMIT 会让分组查询更危险？
加了 ORDER BY COUNT(*) DESC LIMIT 10 后，MySQL 往往放弃走索引分组，转而用临时表 + 文件排序——因为索引无法同时满足分组和按聚合结果排序。这时候光靠组合索引救不了命。
- 先确认是否真需要排序：很多报表其实只看 Top N，可以改用子查询或应用层聚合
- 如果必须排序，且数据量不大，考虑加
SQL_BIG_RESULT提示，让优化器倾向用磁盘临时表而非内存表（避免 OOM） - 极端情况可冗余一个
count_cache字段，用触发器或应用逻辑维护，把分组变成普通查询 - 注意
EXPLAIN中的Using temporary; Using filesort—— 这是明确信号：索引没起作用
WHERE 里用了函数或类型转换，索引还生效吗？
不生效。哪怕你建了完美组合索引，只要 WHERE 条件破坏了索引字段的“可比较性”，整个索引就废了。比如 WHERE DATE(created_at) = '2024-01-01' 或 WHERE user_id + 0 = 123，MySQL 无法用索引快速定位。
- 把函数移到右边：用
WHERE created_at >= '2024-01-01' AND created_at 替代 <code>DATE() - 确保字段类型和参数严格一致：
user_id是BIGINT，就别传字符串'123'，否则隐式转换会丢索引 - 检查
EXPLAIN的key列是否为NULL，以及type是否退化成ALL或index - 对时间范围分组，优先用
created_at做索引前缀，而不是DATE(created_at)衍生字段
组合索引字段太多，会不会反而拖慢写入或占用空间？
会。每多一个字段进索引，B+ 树节点就更大，写入时页分裂更频繁，磁盘占用和内存缓存压力都上升。不是所有字段都值得塞进索引。
- 只保留真正参与
WHERE、GROUP BY、SELECT（非聚合）的字段，删掉“看起来有用”的冗余列 - 区分高频低基数字段（如
status）和低频高基数字段（如order_no）：前者适合放索引前面，后者放进去往往浪费 - 用
SHOW INDEX FROM table_name看Cardinality，如果某字段区分度极低（比如只有 3 个值），它在组合索引里位置越靠后越好 - 上线前用
pt-duplicate-key-checker扫一遍，避免重复索引悄悄吃资源
索引不是越多越好，覆盖不是越全越好。关键在让 MySQL 在一条索引路径上完成“找数据 → 分组 → 取值”三件事，中间不跳转、不排序、不回表。少一个字段可能快十倍，多一个字段可能让写入慢一倍——这个权衡点，得看具体 EXPLAIN 和慢查日志说话。
