数据库索引优化：从B-Tree到覆盖索引

数据库查询慢，十有八九是索引出了问题。但索引并不是越多越好，理解底层原理才能做出正确决策。

B-Tree索引：为什么它最常用

MySQL的InnoDB引擎默认使用B+Tree索引。与哈希索引不同，B+Tree支持范围查询和排序，且所有数据都存储在叶子节点，查询效率稳定为O(log N)。

一个常见的误区是：给每个查询字段都建索引。实际上，索引维护需要成本——每次写入操作都要更新索引树，过多的索引会拖慢写入性能。

联合索引的顺序很重要

联合索引(a, b, c)遵循最左前缀原则。查询条件必须包含a，索引才能生效。如果查询是WHERE b=1 AND c=2，这个索引完全用不上。

设计联合索引时，把区分度最高的字段放在最左边。比如用户表中，email的区分度远高于gender。

覆盖索引：避免回表查询

当查询的所有字段都在索引中时，数据库直接从索引返回结果，无需回表查数据行。这就是覆盖索引。

例如：

CREATE INDEX idx_user ON users(email, username);
SELECT username FROM users WHERE email = 'xxx';

这个查询完全走覆盖索引，性能极佳。

索引失效的常见场景

• 对索引字段做函数运算：WHERE YEAR(created_at) = 2026
• 隐式类型转换：字符串字段传数字
• LIKE以通配符开头：WHERE name LIKE '%tom'
• 使用OR连接不同字段

实战建议

1. EXPLAIN分析每条慢查询
2. 优先优化查询频率高的SQL
3. 定期清理无用索引
4. 考虑读写分离，读库可以多建索引

索引优化是一个持续迭代的过程，没有银弹。理解原理，结合业务场景，才能找到最优解。

---

本文是博客完整版的精简版，更多内容请查看完整版：
阅读原文