数据库索引原理详解：为什么加了索引就快？

你有没有遇到过这样的情况：查一张百万级数据的用户表，没加索引时执行一条 SELECT * FROM users WHERE phone = '13800138000'，等得手机都刷完三遍朋友圈了还没出结果；加上索引后，啪一下，毫秒返回。这背后不是魔法，是数据库索引在干活。

索引就像字典的目录

翻《现代汉语词典》，你想找“熵”字，肯定不会从第一页开始逐字翻——你会先看拼音索引，定位到“shāng”，再翻到对应页码。数据库索引干的就是这事：它不扫描整张表，而是通过一个独立、有序的结构快速定位记录位置。

B+树是主流索引的底层骨架

MySQL 的 InnoDB 引擎默认用 B+ 树实现索引。它长这样：

         [50, 80]
        /    |    \
  [10,30]  [60,70]  [90,95]
  /  |  \   /  \     /  |  \
[1][8][22][55][65][78][85][92][99]

叶子节点存的是**完整的索引值 + 主键（或行指针）**，且所有叶子节点用双向链表连起来——所以范围查询（比如 WHERE id BETWEEN 100 AND 200）特别顺滑。非叶子节点只存“路标”，不存真实数据，所以树能建得又矮又胖，IO 次数少。

主键索引 vs 普通索引：差别在叶子节点

主键索引（聚簇索引）的叶子节点直接存整行数据；而普通索引（二级索引）叶子节点只存主键值。比如给 email 字段建索引：

CREATE INDEX idx_email ON users(email);

查 SELECT name FROM users WHERE email = 'a@b.com' 时，数据库先在 email 索引树里找到对应主键，再回主键索引树查一次完整行——这叫“回表”。如果 SELECT 的字段都在索引里（比如 SELECT email, id），那就不用回表，叫“覆盖索引”，更快。

索引不是越多越好

每建一个索引，增删改都要同步更新多棵树。写入变慢不说，还吃磁盘空间。更坑的是：WHERE a=1 AND b=2 能用上 (a,b) 联合索引，但 WHERE b=2 就用不上——B+ 树按最左前缀排序，b 不是第一列，没法快速定位起始点。

实际调优时，不妨打开 MySQL 的 EXPLAIN 看执行计划：type 是 ref 或 range 说明走了索引；要是 ALL，基本等于全表扫荡。

索引的本质，是用空间换时间，用维护成本换查询效率。理解它怎么组织数据，比死记“一定要给 where 字段加索引”有用得多。