GROUP BY必须用复合索引，因单列索引无法满足最左前缀匹配要求；只有索引列顺序与GROUP BY字段顺序完全一致（如GROUP BY a,b需索引(a,b)或(a,b,c)），且WHERE条件字段前置，才能避免Using temporary和filesort。
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)，否则会回表
WHERE 条件字段必须放索引最左边，顺序错一点就失效
很多人建了 (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 < '2027-01-01'配合(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)))，但老版本只能加冗余字段
怎么验证索引真正在加速 GROUP BY
别只看 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 过滤没生效，或者索引根本没用于分组逻辑
最容易被忽略的是：即使 GROUP BY 字段本身有索引，只要前面的 WHERE 条件没被该索引覆盖，或者字段顺序错位，这个索引对分组阶段就毫无意义——它可能只帮了过滤那一步，分组仍得重建临时结构。
