很多人会误以为："只要出现了 index，就一定走了索引查找"。
但事实完全相反： type 为 index 时，虽然用到了索引文件，但它是"最差"的索引访问方式之一，甚至可以理解为"披着索引外衣的全表扫描"。
我来拆解一下，为什么会出现这种情况，以及它为什么比 ALL 稍微好一点点。
1. 核心概念：什么是 "index" 访问类型？
定义 ：MySQL 会完整遍历整个索引树（Index Full Scan）。
关键区别（一定要分清）：
- range / ref / eq_ref ：是去索引树里精准查找（找特定的几个值），找到就停。
- index ：是把索引树从头到尾扫一遍（像扫全表一样扫索引），一个都不漏！
2. 为什么会遍历整个索引树？
出现这种情况，通常是因为以下两种场景：
场景一：SQL 需要覆盖索引，但优化器选择了全索引扫描
场景描述 ：
你需要查询的数据，都在索引树上包含着（也就是覆盖索引 ），不需要回表去查主键数据。
问题 ：
虽然不需要回表，但因为你的查询条件没有过滤数据（比如 SELECT * FROM t 不加 WHERE），索引树必须把所有叶子节点全部遍历一遍，才能凑齐结果。
例子：
sql
-- 给 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 条件导致的。
避坑建议：
- 避免
SELECT *：只查需要的字段。 - 增加过滤条件 ：加上
WHERE子句，让优化器走range或ref。 - 合理的分页 ：分页深时（如
limit 100000, 20），index会退化成性能极差的操作，需用延迟关联优化。
5. 终极总结图谱
| 场景 | 扫描方式 | 性能等级 | 评价 |
|---|---|---|---|
| range/ref | 精准查找 | ⭐⭐⭐⭐⭐ | 利用索引快速定位，不扫全量 |
| index | 全索引扫描 | ⭐⭐ | 遍历整个索引树，扫全量 |
| ALL | 全表扫描 | ⭐ | 遍历整个数据文件，扫全量 |
口诀：
别看是扫索引，一旦不加条件，全索引扫描也是"坑"。
能走
range不走index，能走ref不走index。