索引扫描为何比全表扫描快

索引扫描比全表扫描快，核心原因在于缩小了需要访问的数据范围，并减少了磁盘 I/O 和比较次数。下面从原理到细节系统说明。

一、全表扫描（Full Table Scan）做了什么？

全表扫描的流程是：

1. 从表的第一行开始
2. 逐行读取数据
3. 对每一行判断是否满足条件
4. 直到表的最后一行

特点：

• 访问整张表的所有数据块
• 即使只有 1% 的数据满足条件，也要读 100% 的数据
• 行数越多，代价线性增长

二、索引扫描（Index Scan）做了什么？

索引本质上是一种有序的数据结构（常见的是 B+Tree），它存储：

• 索引列的值
• 对应数据行的物理位置（如 ROWID、主键）

索引扫描流程（以等值查询为例）：

1. 从索引根节点开始
2. 通过二分查找（B+Tree）快速定位目标值
3. 找到少量索引条目
4. 再根据索引条目回表（如果需要）读取真正的数据

三、为什么索引扫描更快？

✅ 1. 访问的数据量更少（最关键）

例如：

SELECT * FROM orders WHERE order_id = 12345;

• 全表扫描：扫描 1000 万行
• 索引扫描：扫描 3～4 层 B+Tree + 1 行数据

✅ 2. 索引是有序结构，查找效率高

• B+Tree 索引：
  • 高度通常只有 3～4 层
  • 查找复杂度：O(log N)
• 全表扫描：
  • 查找复杂度：O(N)

✅ 3. 减少磁盘 I/O（数据库性能瓶颈）

磁盘 I/O 是数据库最慢的操作：

• 全表扫描：
  • 大量随机或顺序读
  • 可能触发大量页加载
• 索引扫描：
  • 只加载必要的索引页 + 少量数据页

✅ 4. 可以利用索引过滤，避免回表

如果是覆盖索引（Covering Index）：

SELECT order_id FROM orders WHERE order_id = 12345;

• 索引中已经包含 order_id
• 不需要回表
• 性能提升非常明显

四、什么时候索引扫描不一定快？

索引不是银弹，以下情况可能反而更慢：

❌ 1. 返回数据比例太大

SELECT * FROM orders WHERE status = 'ACTIVE';
-- ACTIVE 占 90%

• 索引 + 回表成本 > 全表扫描
• 优化器可能选择全表扫描

❌ 2. 表很小

• 几百行的小表
• 全表扫描反而更简单

❌ 3. 索引选择性差

如：

• 性别（男 / 女）
• 状态位（0 / 1）

索引过滤效果差，扫描成本接近全表

❌ 4. 回表代价过高

• 大量随机 I/O
• 特别是机械硬盘环境

五、用一句话总结

索引扫描快，是因为它通过有序结构快速定位少量数据，避免了扫描整张表，从而大幅减少 I/O 和比较次数。

如果你愿意，我可以：

• 用 B+Tree 图解说明
• 结合 MySQL / Oracle / PostgreSQL 实际执行计划解释
• 给你一个 “什么时候该建索引”的检查清单