什么情况下type为index

很多人会误以为："只要出现了 index，就一定走了索引查找"。
但事实完全相反： type 为 index 时，虽然用到了索引文件，但它是"最差"的索引访问方式之一，甚至可以理解为"披着索引外衣的全表扫描"。

我来拆解一下，为什么会出现这种情况，以及它为什么比 ALL 稍微好一点点。

---

1. 核心概念：什么是 "index" 访问类型？

定义 ：MySQL 会完整遍历整个索引树（Index Full Scan）。

关键区别（一定要分清）：

• range / ref / eq_ref ：是去索引树里精准查找（找特定的几个值），找到就停。
• index ：是把索引树从头到尾扫一遍（像扫全表一样扫索引），一个都不漏！

2. 为什么会遍历整个索引树？

出现这种情况，通常是因为以下两种场景：

场景一：SQL 需要覆盖索引，但优化器选择了全索引扫描

场景描述 ：

你需要查询的数据，都在索引树上包含着（也就是覆盖索引 ），不需要回表去查主键数据。
问题 ：

虽然不需要回表，但因为你的查询条件没有过滤数据（比如 SELECT * FROM t 不加 WHERE），索引树必须把所有叶子节点全部遍历一遍，才能凑齐结果。

例子：

-- 给 name 字段建了索引 idx_name
SELECT name FROM user;

• 逻辑 ：表里有 100 万行，索引树里也有 100 万个 name。MySQL 必须把索引树里的 100 万条记录全部读一遍。
• 结果 ：type = index。

场景二：使用了覆盖索引，但进行了大量排序或分组

场景描述 ：

当你执行 ORDER BY 或 GROUP BY 且排序/分组的字段就是索引列时。
逻辑 ：

因为索引本身就是排序好的，MySQL 可以直接读取索引的顺序来完成排序或分组，不需要额外排序（Using filesort）。但代价是------你得把整个索引树扫完才能确定最终顺序。

---

3. "index" 为什么比 "ALL" 好一点？

既然都是"扫描全部数据"，为什么 index 比 ALL（全表扫描）性能要好？

原因：IO 类型不同

• ALL（全表扫描） ：
  • 读取的是聚簇索引 （主键索引），数据是随机 IO。
  • 磁盘跳跃查找，性能非常低。
• index（全索引扫描） ：
  • 读取的是二级索引 （普通索引），数据是顺序 IO。
  • 因为 B+ 树索引是有序的，数据库可以顺序读取磁盘页，速度远快于随机读。

总结一句话：

都是扫全量数据，但扫索引（index）比扫数据文件（ALL）要快得多！

---

4. 如何避免陷入 "index" 陷阱？

如果在 EXPLAIN 结果中看到 type 是 index，通常是由于 SELECT * 或者没有 WHERE 条件导致的。

避坑建议：

1. 避免 SELECT *：只查需要的字段。
2. 增加过滤条件 ：加上 WHERE 子句，让优化器走 range 或 ref。
3. 合理的分页 ：分页深时（如 limit 100000, 20），index 会退化成性能极差的操作，需用延迟关联优化。

5. 终极总结图谱

场景	扫描方式	性能等级	评价
range/ref	精准查找	⭐⭐⭐⭐⭐	利用索引快速定位，不扫全量
index	全索引扫描	⭐⭐	遍历整个索引树，扫全量
ALL	全表扫描	⭐	遍历整个数据文件，扫全量

口诀：

别看是扫索引，一旦不加条件，全索引扫描也是"坑"。

能走 range 不走 index，能走 ref 不走 index。