索引如何建立才能加速SQL中的GROUP BY查询？-SQL-PHP中文网

group by必须用复合索引，因单列索引无法满足最左前缀匹配要求；只有索引列顺序与group by字段顺序完全一致（如group by a,b需索引(a,b)或(a,b,c)），且where条件字段前置，才能避免using temporary和filesort。

索引如何建立才能加速sql中的group by查询？

因为 MySQL 的 GROUP BY 只能利用索引的最左前缀顺序来跳过排序和临时表。单列索引哪怕建在 region 上，只要查询是 GROUP BY region, category，就无法避免 Using temporary——B+ 树不支持跨列跳跃匹配。

真正起效的索引必须字段数、顺序、类型三者完全对齐：

GROUP BY a, b → 索引必须是 (a, b) 或 (a, b, c)，不能是 (b, a) 或只建 (a)
WHERE status = 'active' GROUP BY region, city → 索引必须是 (status, region, city)，status 必须最左
如果还查 SUM(amount)，就把 amount 加到末尾：(status, region, city, amount)，否则会回表

很多人建了 (region, city) 索引，但查询带 WHERE status = 'active'，结果执行计划里还是 type=ALL。这不是索引没建，是它根本没被选中——优化器发现索引开头不是 status，无法加速过滤，干脆弃用。

正确做法是把筛选性强、值分布均匀的字段前置：

status（只有 active/inactive）比 city（上千个值）选择性低，但 WHERE 中等值匹配稳定，适合放最左
如果 WHERE created_at >= '2026-01-01' AND status = 'active' GROUP BY region，优先建 (status, created_at, region) 而非 (created_at, status, region)——范围查询后无法继续用索引做等值匹配
别信“高基数字段放前面”，对 GROUP BY 来说，WHERE 条件的匹配效率永远优先于分组字段的选择性

哪怕索引定义完美，SQL 里一个函数或一次隐式转换就能让它完全失效。执行计划里一旦出现 Using temporary 或 Using filesort，基本可以判定是这类问题。

GROUP BY YEAR(create_time) → 索引存的是原始时间戳，函数结果无法走 B+ 树查找；应改用 WHERE create_time >= '2026-01-01' AND create_time 配合 <code>(create_time) 索引
WHERE user_id = '123'（user_id 是 INT）→ 触发隐式转换，全索引扫描；必须写成 WHERE user_id = 123
SELECT *, COUNT(*) FROM t GROUP BY dept → * 强制回表，覆盖索引破防；改成 SELECT dept, COUNT(*) 才可能命中 (dept)
GROUP BY UPPER(name) → 普通索引无效；MySQL 8.0+ 可建函数索引 INDEX idx_name_upper ((UPPER(name)))，但老版本只能加冗余字段

别只看 key 列有没有值。关键看三处：

type 字段：必须是 ref、range 或 const，绝不能是 ALL 或 index（后者表示全索引扫描，代价接近全表）
Extra 字段：严禁出现 Using temporary（已用磁盘临时表）和 Using filesort（额外排序），理想状态是 Using index for group by（MySQL 8.0+）或至少 Using index
rows 值：如果显示扫描 500 万行，但最终只返回 200 个分组，说明 WHERE 过滤没生效，或者索引根本没用于分组逻辑