索引原理与类型：B+树索引结构、聚簇索引与非聚簇索引、联合索引与最左前缀原则
聊到数据库优化，索引绝对是绕不开的核心话题。我见过太多开发同学，SQL 写得很溜，但一到索引设计就抓瞎。说白了，索引就像书的目录——没有它，你得一页页翻；有了它，直接定位到目标页。但索引也不是越多越好，用错了反而拖累性能。
今天咱们就深入聊聊索引的底层原理和几种常见类型。嗯，这里我会结合自己踩过的坑来讲，希望能帮你少走弯路。
B+树索引结构：为什么它成了主流？
先问个问题：为什么 MySQL 的 InnoDB 引擎选择了 B+树，而不是二叉树、哈希表或者红黑树？
我个人习惯从磁盘 I/O 的角度来理解。数据库的数据是存在磁盘上的，磁盘读写一次叫一次 I/O，这玩意儿很慢。所以索引设计的目标就是：用最少的 I/O 次数找到目标数据。
- 二叉树：每个节点最多两个子节点。数据量一大，树就特别高。比如 100 万条数据，树高大约 20 层。查一次要读 20 次磁盘，太慢了。
- 红黑树：本质也是二叉树，虽然自平衡，但树高依然随数据量线性增长。
- 哈希表：等值查询极快（O(1)），但范围查询（比如
WHERE age > 20）就废了，而且不支持排序。 - B+树：每个节点可以存多个键值，并且叶子节点之间用指针串联成有序链表。树高通常只有 3-4 层，查询任何数据最多 3-4 次 I/O。
核心结论：B+树通过“矮胖”的结构，把磁盘 I/O 次数降到了最低。同时叶子节点的有序链表，让范围查询和排序变得非常高效。
我在项目中遇到过这样一个场景：一张订单表有 5000 万行数据，最初用的哈希索引做等值查询，速度确实快。但业务方突然要查“某个月的所有订单”，哈希索引直接失效，全表扫描跑了 40 多秒。后来改成 B+树索引，同样的查询 0.3 秒就出结果了。你想想看，选错索引类型代价有多大。
聚簇索引与非聚簇索引：数据到底存哪儿？
这是面试高频题，也是实际开发中容易混淆的地方。我直接说人话：
- 聚簇索引：数据和索引是“长在一起”的。索引的叶子节点直接存的是整行数据。
- 非聚簇索引：数据和索引是分开的。索引的叶子节点存的是主键值（或者行指针），查到主键后还得回表查数据。
在 InnoDB 里，主键索引就是聚簇索引。如果你没定义主键，InnoDB 会选一个唯一非空列，实在没有就自己生成一个隐藏的 6 字节 rowid 作为聚簇索引。
| 对比项 | 聚簇索引 | 非聚簇索引 |
|---|---|---|
| 数据存储位置 | 索引叶子节点直接存数据行 | 索引叶子节点存主键值 |
| 查询速度 | 直接命中数据，无需回表 | 查到主键后，需要回表查一次 |
| 数量限制 | 一个表只能有一个 | 一个表可以有多个 |
| 适用场景 | 主键查询、范围查询 | 非主键列的查询 |
我的建议：建表时一定要显式定义主键，而且最好用自增整数或雪花算法生成的 ID。为什么？因为聚簇索引的物理存储是按主键顺序排列的。如果你用 UUID 这种随机字符串做主键，插入时会导致频繁的页分裂，性能会急剧下降。我曾经帮一个客户优化过一张表，把 UUID 主键改成自增 ID 后，写入性能提升了 5 倍。
联合索引与最左前缀原则：别让你的索引白建
联合索引，说白了就是多个列一起建一个索引。比如 INDEX idx_name_age (name, age)。但这里有个大坑——最左前缀原则。
什么意思？联合索引的 B+树会先按第一个字段排序，第一个字段相同再按第二个字段排序。所以查询时，必须从最左边的列开始匹配，跳过左边的列直接查右边的列，索引就失效了。
举个例子：
-- 建一个联合索引
CREATE INDEX idx_name_age_sex ON user(name, age, sex);
-- 能用到索引的查询
SELECT * FROM user WHERE name = '张三'; -- 用到了 name
SELECT * FROM user WHERE name = '张三' AND age = 25; -- 用到了 name 和 age
SELECT * FROM user WHERE name = '张三' AND age = 25 AND sex = '男'; -- 全用上了
-- 用不到索引的查询
SELECT * FROM user WHERE age = 25; -- 跳过了 name，索引失效
SELECT * FROM user WHERE sex = '男'; -- 跳过了 name 和 age，索引失效
SELECT * FROM user WHERE age = 25 AND sex = '男'; -- 同样失效
我曾经踩过的坑：有一次我建了一个联合索引 (status, create_time)，心想查 status 和 create_time 都能快。结果业务方写了个查询 WHERE create_time BETWEEN '2023-01-01' AND '2023-01-31'，没带 status。索引完全没用上，全表扫描跑了 10 秒。后来我调整了索引顺序，把 create_time 放在最左边，或者单独给 create_time 建一个索引，问题才解决。
这里再补充一个实用技巧：索引下推。MySQL 5.6 之后引入的优化。比如联合索引 (name, age)，查询条件是 WHERE name LIKE '张%' AND age = 25。以前的做法是：先通过 name 模糊匹配找到所有主键，然后回表，再过滤 age。现在有了索引下推，在索引遍历过程中就直接判断 age 条件了，减少了回表次数。嗯，这个优化对 LIKE 查询特别友好。
如何选择合适的索引？
说了这么多理论，最后给点实战建议：
- 区分度高的列优先：比如性别字段，只有男女两种值，区分度太低，建索引意义不大。而身份证号、手机号这种几乎唯一的字段，索引效果极好。
- 频繁作为查询条件的列：出现在 WHERE、JOIN、ORDER BY、GROUP BY 中的列，优先考虑建索引。
- 联合索引的列顺序：把区分度高的列放左边，经常等值查询的列放左边，范围查询的列放右边。
- 避免冗余索引：比如已经有了 (a, b) 联合索引，再单独建一个 (a) 索引就是浪费，因为前者已经覆盖了后者的功能。
- 小表不要建索引：一张表就几百行数据，全表扫描比走索引还快，因为索引本身也有维护成本。
一句话总结：B+树是 InnoDB 的基石，聚簇索引决定了数据怎么存，联合索引用好了能大幅提升查询效率，但必须遵守最左前缀原则。索引不是越多越好，关键是要精准。
好了，这一章的内容就到这里。下一章咱们聊聊 SQL 执行计划，教你如何用 EXPLAIN 分析慢查询。到时候我会分享一个真实案例——一条 SQL 从 30 秒优化到 0.1 秒的全过程，敬请期待。