什么时候发生索引扫描

在数据库中，“索引扫描（Index Scan）”是查询优化器选择使用索引来定位或读取数据的一种方式。简单地说，当查询可以利用索引来避免全表扫描、提高检索效率时，就会发生索引扫描。

下面从“什么时候会发生”和“不同类型的索引扫描”两个角度来说明。

一、什么时候会发生索引扫描？

通常满足以下条件时，优化器更可能选择索引扫描：

1. 查询条件命中索引列

例如：

SELECT * FROM user WHERE id = 100;

如果 id 上有索引，通常会发生索引扫描（甚至索引查找）。

2. 查询只涉及索引中的列（覆盖索引）

SELECT name FROM user WHERE age > 20;

如果 (age, name) 是联合索引，数据库可以直接从索引中返回结果，发生索引覆盖扫描。

3. 需要排序或范围查询，且索引支持

SELECT * FROM order ORDER BY create_time;

如果 create_time 有索引，可能直接按索引顺序扫描，避免额外排序。

4. 返回数据量较小

优化器估算：

• 走索引成本 < 全表扫描成本
• 回表代价可接受

就会选择索引扫描。

5. 连接（JOIN）时使用索引

SELECT * FROM a JOIN b ON a.id = b.a_id;

若 b.a_id 有索引，常发生索引扫描（如 Index Nested Loop Join）。

二、常见的索引扫描类型（以 MySQL / Oracle 为例）

1. 索引全扫描（Index Full Scan）

• 遍历整个索引
• 通常比全表扫描快（索引更小）
• 例如：索引覆盖查询

2. 索引范围扫描（Index Range Scan）

• >, <, BETWEEN, IN, LIKE 'abc%'
• 最常见

3. 索引唯一扫描（Index Unique Scan）

• 主键或唯一索引
• 最多返回一行

4. 索引快速全扫描（Index Fast Full Scan）

• 多发生在并行或覆盖查询
• 不保证顺序

5. 索引跳跃扫描（Index Skip Scan）

• 联合索引前导列未使用，但优化器“跳过”

三、什么时候“不会”发生索引扫描？

• 对索引列使用函数：WHERE DATE(create_time) = ...
• 隐式类型转换
• 前导模糊：LIKE '%abc'
• 优化器认为回表成本太高
• 数据量极小，全表更快

四、一句话总结

当查询条件、排序、覆盖列能被索引有效支持，并且使用索引比全表扫描更省成本时，就会发生索引扫描。

如果你指的是某种具体数据库（MySQL / Oracle / PostgreSQL）或具体 SQL 场景，我可以给你更精确的解释。