Full Index Scan（MySQL中type为index）是遍历索引B+树全部叶子节点的扫描方式，非全表扫描但效率低于高效索引查询；而ALL是直接扫描数据页的无序全表扫描，I/O更随机、开销通常更大。
Full Index Scan 是什么，和 ALL 有什么区别
full index scan（mysql 中显示为 index，postgresql 中叫 index scan，oracle 中对应 index full scan）不是全表扫描，但也不是高效索引查询。它表示数据库**遍历整棵索引树的叶子节点**，逐条读取索引键值，再回表（或直接返回索引列）——前提是查询字段能被该索引覆盖。
对比 ALL（全表扫描）：
– ALL 扫描的是数据页（.ibd / heap pages），无序、无结构，I/O 更随机；
– index 扫描的是有序的索引页（B+Tree 叶子链表），顺序 I/O 更多，但依然要读完整个索引结构。
关键差异点：
– 行数相同时，index 通常比 ALL 快 10%~30%，因为索引页更小、更紧凑；
– 但如果索引列宽大（如含 TEXT、长 VARCHAR），或需要频繁回表，index 可能比 ALL 还慢；
– index 无法利用索引的“跳过”能力（如范围裁剪、等值定位），本质上仍是暴力遍历。
什么时候会出现 Full Index Scan，是不是优化失败信号
出现 index 类型执行计划，常见于以下几种情况：
- 查询只涉及索引列，且没加 WHERE 条件，例如
SELECT id FROM users;—— 这是合理用法，避免了回表 - WHERE 条件匹配了索引最左前缀，但后续列用了范围查询，导致索引“截断”，例如
WHERE a = 1 AND b > 100对索引(a, b, c)，c 列就失效了，扫描范围扩大 - 索引选择性极低（如
gender只有 'M'/'F'），优化器判断走索引不如全表扫描 - 统计信息陈旧，
ANALYZE TABLE users;未执行，让优化器误估行数
它不等于“错误”，但确实是**未精准命中索引能力**的表现。如果你本意是查某几个 ID 或按时间范围快速过滤，却看到 index，说明索引设计或查询写法有问题。
如何判断 Full Index Scan 是否真慢，看哪几列最关键
在 Navicat 的 Explain 结果里，盯住这三列：
-
rows：显示预估扫描行数。如果它接近表总行数（比如表有 100 万行，rows=982341），那基本就是“伪索引”——和全表扫差不多 -
key：确认实际使用的索引名。若为空，说明根本没走索引；若非空但rows极高，说明索引没被有效利用 -
Extra：出现Using index是好事（仅靠索引就能返回结果）；若出现Using where; Using index，说明索引扫描后还要逐行过滤，性能打折；若带Using filesort或Using temporary，问题已升级
特别注意：PostgreSQL 的 Index Scan 和 MySQL 的 index 含义不完全等价——PG 的 Index Scan 可能只扫部分叶子页，而 MySQL 的 index 几乎总是全量扫描索引叶子节点。
想避开 Full Index Scan，实际能改什么
不是所有 index 都能/应该被干掉，但多数可优化：
- 加 WHERE 条件：哪怕只是
WHERE id IS NOT NULL，有时也能触发更优的range或ref访问类型 - 调整联合索引顺序：确保高频等值条件字段放在最左，例如把
(created_at, status)改成(status, created_at)，让WHERE status = 'active'能启动索引 - 用覆盖索引替代：把 SELECT 字段都包含进索引，例如
CREATE INDEX idx_user_cover ON users(status, created_at) INCLUDE (name, email);（SQL Server）或CREATE INDEX idx_user_cover ON users(status, created_at, name, email);（MySQL） - 避免 SELECT *：它大概率触发回表，把原本可能的
Using index拉低成Using where; Using index
真正容易被忽略的是：即使 index 看起来“比 ALL 好一点”，只要 rows 没显著下降，它的单位成本（CPU + I/O）可能更高——因为索引页虽小，但访问路径更深、分支更多，缓存局部性反而更差。
