为什么索引扫描变慢了

索引扫描（Index Scan）本来是为了“加速查询”而存在的，但在实际生产里，经常会出现**“明明走了索引，却还是很慢”的情况。下面按最常见原因 → 现象 → 解决思路**来说明。

一、最常见原因

1️⃣ 回表过多（Index Scan + Table Access）

现象

• 执行计划是 INDEX SCAN
• 但 ROWS 很大
• 响应时间随数据量线性增长

原因

• 索引只覆盖了过滤条件
• 但 SELECT 的列不在索引里，需要回表

例子

SELECT *
FROM orders
WHERE user_id = 123;

• user_id 有索引
• 但 * 需要读整行 → 大量回表

解决

• 建覆盖索引

CREATE INDEX idx_user ON orders(user_id) INCLUDE (status, amount);

2️⃣ 索引选择性差（低基数列）

现象

• 走了索引
• 但扫描行数 ≈ 全表

原因

• 索引列重复值太多（如 status, gender）

例子

WHERE status = 'ACTIVE'

• 如果 90% 都是 ACTIVE，索引毫无意义

解决

• 联合更高基数列
• 或不用索引，直接全表

3️⃣ 索引失效（隐式类型转换 / 函数）

现象

• 本来该走索引
• 现在变慢，执行计划变了

常见写法

WHERE DATE(create_time) = '2024-01-01'
WHERE user_id = '123'   -- user_id 是 int

解决

• 不要对索引列使用函数
• 保持类型一致

4️⃣ 排序 / 分页导致额外代价

现象

• ORDER BY + LIMIT
• 索引扫描后还要排序

原因

• 索引顺序 ≠ 排序顺序

例子

WHERE user_id = 1
ORDER BY create_time DESC

需要：

INDEX(user_id, create_time)

5️⃣ 统计信息过期（执行计划误判）

现象

• 之前很快
• 某天突然变慢
• 数据量没明显变化

原因

• 统计信息不准
• 优化器选错扫描方式

解决

ANALYZE TABLE orders;

6️⃣ 锁 / IO / 资源竞争

现象

• 单条 SQL 慢
• 系统整体变慢

可能原因

• 磁盘 IO 瓶颈
• 热块争用
• 长事务锁表

7️⃣ 索引本身太大 / 碎片严重

现象

• 扫描行数不多
• 但耗时高

原因

• 索引分裂
• 页不连续

解决

• 重建索引

ALTER INDEX idx_xxx REBUILD;

二、如何快速定位？

✅ 看执行计划

重点看：

• type（range / ref / index）
• rows
• Extra
  • Using index（好）
  • Using where; Using index（还行）
  • Using filesort（危险）

✅ 对比

• 以前快不快？
• 数据量变化？
• 是否刚 ANALYZE？

三、一句话总结

索引扫描变慢，通常不是“索引没用”，而是“用错了方式”或“用得太重”。

如果你愿意，可以把：

• 数据库类型（MySQL / PostgreSQL / Oracle）
• SQL
• 执行计划

发出来，我可以直接帮你定位是哪一类问题。