怎样减少索引扫描开销

减少索引扫描（Index Scan）开销通常从“让索引更高效、让扫描更少、让返回更轻”三个方向入手。下面按常见场景给你一套实用思路：

一、减少索引扫描的行数（最核心）

1. 加强 WHERE 条件选择性

• 使用高选择性字段作为索引前缀
• 避免对索引列做函数/运算

--  bad
WHERE DATE(create_time) = '2024-01-01'

--  good
WHERE create_time >= '2024-01-01'
  AND create_time < '2024-01-02'

2. 利用复合索引最左前缀

INDEX(a, b, c)

能用到索引的查询：

WHERE a=?
WHERE a=? AND b=?

不能用到：

WHERE b=?

3. 避免隐式类型转换

WHERE phone = 1380000000  -- phone 是 varchar

会导致索引失效。

二、减少回表（Random IO）

4. 使用覆盖索引（Covering Index）

INDEX(user_id, status)

查询：

SELECT user_id, status
FROM order
WHERE user_id = 1

不需要回表。

✅ 把经常查询的字段放进索引

三、减少索引本身的大小

5. 精简索引列

• 不用长字符串做索引前缀
• 可用前缀索引：

INDEX(name(20))

6. 控制索引数量

• 索引不是越多越好
• 写多读少表：减少索引

四、避免“伪索引扫描”

7. 避免这些导致索引失效的情况

• != / NOT IN
• OR 非全部索引列
• LIKE '%xx'
• 索引列参与计算

五、让扫描方式更优

8. 利用索引有序性

ORDER BY create_time
INDEX(create_time)

避免 filesort。

9. 分页优化（深分页很贵）

-- bad
LIMIT 100000, 10

-- good
WHERE id > 100000
ORDER BY id
LIMIT 10

六、数据库层优化

10. 调整参数（以 MySQL 为例）

• innodb_buffer_pool_size ↑（缓存索引）
• 合理 read_ahead
• 定期 ANALYZE TABLE

七、架构层（高并发场景）

• 读写分离
• 冷热数据分离
• ES / 列式存储替代复杂索引扫描

快速自查清单 ✅

• [ ] 是否用到了正确索引？
• [ ] 是否回表？
• [ ] 是否扫描了不必要的数据？
• [ ] 是否深分页？
• [ ] 是否索引失效？

如果你能给我：

• 数据库类型（MySQL / PG / Oracle）
• 表结构 + 索引
• 慢 SQL

我可以直接帮你针对性优化。