能，但需满足GROUP BY字段顺序与复合索引最左前缀完全一致，且范围条件不能截断索引；否则无法利用索引有序性避免临时表和filesort。
复合索引能加速GROUP BY吗？能，但有条件
能——前提是 GROUP BY 字段顺序和复合索引最左前缀完全一致，且没有被范围条件截断。不能——比如 WHERE a > 10 GROUP BY b, c，a 是范围查询，b 和 c 又不在索引最左，那这个索引基本白建。
MySQL 在执行分组时，如果能利用索引的有序性直接归并（避免临时表 + filesort），性能提升会非常显著。但注意：它不会为 GROUP BY 单独“重排”索引顺序，只认你定义的字段顺序。
- ✅ 有效场景：
SELECT city, age, COUNT(*) FROM users WHERE status = 1 GROUP BY city, age→ 对应索引INDEX(status, city, age) - ❌ 无效场景：
SELECT age, city FROM users GROUP BY age, city→ 若索引是(city, age)，则无法跳过city直接按age分组 - ⚠️ 注意：如果
SELECT中有非分组字段（如SELECT city, age, name），即使索引覆盖了city, age，name仍需回表，除非你建的是覆盖索引（把name也加进索引末尾）
WHERE + GROUP BY 混合查询，索引字段怎么排？
优先满足「过滤先行、分组次之、范围靠右」。不是按 SQL 里写的顺序，而是按数据分布和查询模式决定。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 等值条件（
=、IN）放最左：它们能精确锁定 B+ 树分支，比如status = 'active'或user_id IN (101, 102) - 高选择性字段优先：比如
user_id（唯一值多）比gender（只有男/女）更适合放第一列 -
GROUP BY字段紧接其后：且必须连续、顺序一致。例如想按region, product_type分组，索引就该是(status, region, product_type)，而不是(status, product_type, region) - 范围条件（
>、BETWEEN）放最后：一旦出现，后续字段只能用于排序或覆盖，不能再参与WHERE或GROUP BY过滤
为什么EXPLAIN显示key用了，但rows还是很大？
常见于「索引用了一半就停了」。比如索引是 (a, b, c)，查询是 WHERE a = 1 AND c > '2024-01-01'，b 缺失导致 c 无法走索引下探，MySQL 实际只用了 a，后面全靠扫描。
- 看
key_len：假设a是 INT（4 字节）、b是 VARCHAR(50)（最大 50+1 字节）、c是 DATE（3 字节），那完整命中三列 key_len 应 ≈ 58；若实际只有 4，说明只用了a - 检查是否对索引列用了函数：
WHERE YEAR(created_at) = 2024→ 索引失效；改成created_at >= '2024-01-01' AND created_at - 确认字符集/排序规则是否一致：比如字段是
utf8mb4_0900_as_cs，但查询字符串隐式转成utf8mb4_general_ci，也可能导致索引不匹配
分组字段太多，建一个大复合索引还是多个小索引？
别贪多，先看实际高频组合。一个包含 5 列的索引 (a,b,c,d,e) 并不意味着所有子集都能高效使用——只要中间断一环，后面全废。
- 如果业务中稳定存在两组查询：
WHERE x=1 GROUP BY y,z和WHERE x=1 AND y='A' GROUP BY z，那INDEX(x, y, z)就够用 - 但如果还有独立查
y或单独按z分组的需求，再额外补INDEX(y)和INDEX(z)更实际 - 特别警惕低区分度字段塞进左侧：比如
is_deleted TINYINT只有 0/1，放在复合索引第一位，会导致整棵树几乎一半节点都得遍历，收益极低
真正容易被忽略的是：复合索引生效与否，不取决于你写了多少条件，而取决于优化器能不能从 B+ 树根节点一路无中断地走到叶子节点。任何隐式类型转换、函数包裹、OR 条件、或者字段顺序错位，都会让这条路中途断掉。
