联合索引对GROUP BY有效需严格满足最左前缀连续性：WHERE与GROUP BY字段必须在索引中从左到右连续排列，范围查询会截断右侧分组字段；松散索引扫描（Using index for group-by）仅适用于COUNT(*)、MIN()、MAX()等聚合且无范围条件时。
能，但必须严格满足列顺序和连续性要求，否则索引对 GROUP BY 无效。
联合索引列顺序必须与 GROUP BY + WHERE 的组合逻辑完全对齐
MySQL 不会“智能重排”索引列。如果查询是 WHERE city = ? AND age > ? GROUP BY dept，而你建了 (city, dept, age) 索引，GROUP BY 仍然用不上——因为 dept 被 age 隔开了，不满足最左前缀连续性。
正确做法是把 GROUP BY 列放在 WHERE 条件列的“右侧连续位置”：
- 若只
GROUP BY dept，索引应为(dept)或(city, dept)或(city, age, dept) - 若
WHERE city = ? GROUP BY dept，推荐(city, dept)——city用于快速过滤，dept用于分组扫描 - 若
WHERE city = ? AND age BETWEEN 25 AND 35 GROUP BY dept, role，索引应为(city, age, dept, role)，不能跳过age直接写(city, dept, role)
松散索引扫描（Loose Index Scan）是性能跃升的关键信号
当 EXPLAIN 的 Extra 字段出现 Using index for group-by，说明 MySQL 正在用松散索引扫描：它只读每个分组的第一条索引记录，跳到下一个分组值，完全避开临时表和排序。
但这个模式有硬限制：
- 只能用于
COUNT(*)、MIN()、MAX()这类聚合函数 - SELECT 中所有非聚合列，必须全部包含在索引里（即覆盖索引）
- WHERE 条件不能含范围查询（如
>、BETWEEN、LIKE 'abc%'），否则退化为紧凑索引扫描
例如：SELECT dept, COUNT(*) FROM staff WHERE city = 'Beijing' GROUP BY dept，配合 (city, dept) 索引，就能触发松散扫描；但加个 AND age > 25，就失效了。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
WHERE 和 GROUP BY 列冲突时，优先保 WHERE，再看 GROUP BY 是否顺带受益
MySQL 优化器不会为了 GROUP BY 牺牲 WHERE 效率。如果 WHERE city = ? AND status = ? 是高频条件，而 GROUP BY dept 是低频报表需求，建索引时应以 (city, status) 为主，dept 放后面只是锦上添花。
真正要警惕的是“伪覆盖”：比如建了 (city, dept, salary)，但查询是 WHERE city = ? GROUP BY dept ORDER BY AVG(salary)——AVG() 不在松散扫描支持范围内，且 ORDER BY 又引入额外排序，此时索引对 GROUP BY 的帮助非常有限，Extra 很可能还是 Using temporary; Using filesort。
别忘了 ANALYZE TABLE 和 EXPLAIN 验证
即使索引结构完全正确，优化器也可能因统计信息陈旧而放弃使用它。上线新索引后必须执行：
-
ANALYZE TABLE staff更新行数、基数等统计信息 -
EXPLAIN FORMAT=TRADITIONAL查看key是否命中预期索引，rows是否显著下降，Extra是否出现Using index for group-by或至少Using index - 避免只看
possible_keys—— 它只是候选，key才是实际选择
最常被忽略的一点：复合索引中列的顺序一旦定下，就同时锁死了 WHERE 过滤粒度和 GROUP BY 扫描路径，改一个列的位置，可能让两个场景全崩。设计时得拿真实查询反复对齐，不能只看单个条件。
