group by 本身不必然导致全表扫描，真正触发它的是分组字段无索引、where条件未利用索引或select字段超出索引覆盖范围；需按where列、group by列、select非聚合列顺序建立联合覆盖索引，并避免函数操作与隐式类型转换。

GROUP BY 本身不必然导致全表扫描，真正触发它的，是分组字段没索引、WHERE 条件没利用上索引，或 SELECT 字段超出索引覆盖范围。

为什么 GROUP BY 会触发全表扫描

数据库执行 GROUP BY 时，需要按分组字段排序或哈希。如果 GROUP BY 字段没有索引，或索引无法支持当前查询（比如顺序错、缺失 WHERE 列），优化器就只能扫全表构建临时结果集——这时 EXPLAIN 里会出现 Using temporary; Using filesort。

• 常见诱因：只建了 (b, a) 索引，却写 GROUP BY a, b
• WHERE 中对索引列用了函数，比如 WHERE DATE(create_time) = '2024-01-01'，索引失效
• SELECT * 或包含非索引字段，迫使回表，间接让索引“不够用”

怎么建索引才能让 GROUP BY 走索引

核心是让索引同时覆盖 WHERE 过滤 + GROUP BY 分组 + SELECT 输出字段，即“联合覆盖索引”。

• 顺序必须严格左前缀：GROUP BY a, b → 索引至少为 (a, b)；若还有 WHERE c = ?，优先建 (c, a, b)
• 如果 SELECT 包含 sum(price)，而 price 不在索引里，就得回表——此时应把 price 加到索引末尾，变成 (c, a, b, price)
• 避免冗余：(a, b, c) 已存在，再建 (a, b) 没意义，还拖慢写入

哪些写法会让索引彻底失效

即使索引建对了，SQL 写法不对照样白搭。这些操作会让优化器放弃使用索引：

• 在 GROUP BY 字段上用函数：GROUP BY YEAR(create_time) → 改成先用 WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31' 缩小范围，再 GROUP BY 原始字段
• OR 连接条件：WHERE status = 1 OR type = 'vip' → 拆成 UNION ALL 或改用 IN（前提是字段有索引）
• 隐式类型转换：WHERE user_id = '12345'（user_id 是 BIGINT）→ 字符串强制转数字，索引失效；必须传整型参数

EXPLAIN 怎么看才算真正避开了全表扫描

不能只看 key 是否非 NULL，关键要三者同时满足：

• key 显示用了哪个索引（不是 NULL）
• Extra 里**没有** Using temporary 和 Using filesort
• SELECT 所有字段（含 GROUP BY 列）都在该索引定义中——哪怕只多一个 text 字段没包含，也会回表，失去覆盖意义

最容易被忽略的是：索引列顺序错了、WHERE 条件漏了高选择性字段、或者以为建了单列索引就能撑起复合分组——实际几乎没用。