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 输出又不够直白，让人误以为是数据库的问题。