GROUP BY索引失效本质是优化器成本计算后认为全表扫描更优，主因包括分组字段未对齐索引顺序、函数/隐式转换中断有序性、非覆盖字段引发回表，或WHERE未走索引导致后续优化失效。
索引在 GROUP BY 场景下失效，根本不是“数据库故意不走”，而是优化器算完成本后发现：走索引 + 回表 + 排序/哈希，比直接全表扫描还贵——尤其当数据量小、过滤条件弱、或索引设计没对齐查询模式时。
GROUP BY 没走索引，本质是没用上索引的有序性
MySQL 和 Oracle 的 GROUP BY 高效执行依赖索引天然的排序能力。一旦分组字段顺序与索引列顺序不一致，或中间被函数、非索引列、隐式转换打断，优化器就无法复用索引做流式分组，只能退回到全表扫描 + 临时表聚合。
-
GROUP BY user_id, status要走索引，索引必须是(user_id, status)或更长的左前缀（如(user_id, status, created_at)），(status, user_id)不行 -
GROUP BY DATE(created_at)会让整个索引失效——因为索引里存的是2026-10-15 12:45:33，不是'2026-10-15' - 即使
WHERE条件命中了索引，但SELECT里带了非索引字段（比如name），也会触发回表；若回表代价高，优化器可能直接放弃索引
EXPLAIN 中看到 Using temporary 就等于没走索引分组
Using temporary 是最明确的信号：数据库正在内存或磁盘建临时表来完成分组，说明索引既没用于过滤，也没用于分组排序。此时 type 往往是 ALL 或 index，key 为空或非预期索引。
- 别只盯着
key是否有值——key显示用了某个索引，但Extra里仍有Using temporary; Using filesort，说明索引只帮了WHERE，没帮上GROUP BY -
key_len值偏小（比如联合索引(a,b,c)，但key_len只显示前两列长度），说明第三列没参与索引查找，GROUP BY无法利用其有序性 - Oracle 中对应现象是执行计划出现
TABLE ACCESS FULL或SORT GROUP BY（而非INDEX RANGE SCAN+GROUP BY）
覆盖索引是解决 GROUP BY 全表扫描最直接的手段
覆盖索引要求：所有 WHERE 过滤字段 + 所有 GROUP BY 字段 + 所有 SELECT 中的非聚合字段，全部包含在同一个联合索引中，且顺序满足左前缀原则。
- 写法示例：
SELECT user_id, status, COUNT(*) FROM orders WHERE created_at >= '2026-01-01' GROUP BY user_id, status→ 索引应建为(created_at, user_id, status)，把过滤字段放最左 - 如果还要
SELECT MAX(amount)，就把amount加到索引末尾：(created_at, user_id, status, amount)，避免回表 - 别把
TEXT或BLOB字段加进索引——它们不支持索引，强行加会导致建索引失败或自动截断
WHERE 条件没走索引，GROUP BY 再怎么优化也白搭
很多人忽略一个关键事实：GROUP BY 是在 WHERE 过滤之后才执行的。如果 WHERE 条件本身触发了全表扫描，后续所有优化都失去意义。
-
WHERE status = 'PENDING' AND create_time >= TO_DATE('2026-01-01', 'YYYY-MM-DD')—— 若status区分度低（比如只有 3 个值），而create_time上没索引或索引顺序不对，优化器大概率选全表扫描 -
WHERE order_no = 'ORD20261015'却慢？检查order_no类型是VARCHAR2，但传参是数字20261015，Oracle 会自动加TO_NUMBER()，索引失效 -
WHERE name LIKE '%张'是左模糊，B+ 树无法定位起点，必然全表扫——这种场景改用全文索引或预计算字段更现实
真正难处理的从来不是“要不要建索引”，而是“建哪个索引、按什么顺序、覆盖哪些字段”。很多问题查到一半就停在“索引存在”，却没验证它是否被真正使用；更多时候，是 SQL 写法悄悄绕过了索引，而 EXPLAIN 输出又不够直白，让人误以为是数据库的问题。
