> 索引基础：B+树详解

---

大家好，我是一名拥有10年以上经验的DBA老兵。

做这个系列，源于一个朴素的愿望：把踩过的坑、总结的经验系统化输出，希望能帮到刚入行或想进阶的兄弟们。

让我们开始今天的第5天内容。

---

## 背景引入

> 💡 说白了：索引就是一本书的目录。没有目录，你想找"事务"这个词，只能一页一页翻；有了目录，直接翻到对应页码。

很多同学知道索引能加速查询，但面试官一问"B+树为什么比B树适合做索引？""为什么不用二叉树？"——就懵了。

**今天的目标**：搞懂B+树结构，面试必问！

---

## 核心概念

### 一、没有索引会怎样？

没有索引时，MySQL只能**全表扫描**——从第一行开始，逐行对比，直到找到目标。

```sql
-- 没有索引时，查找name='张三'要扫描全表
SELECT * FROM user WHERE name = '张三';

-- EXPLAIN 查看执行结果（type=ALL，说明全表扫描）
-- type列值：ALL → 全表扫描，性能最差
```

假设一张表100万行，找一个值最多要对比100万次。这就是为什么索引这么重要。

---

### 二、为什么是B+树？

面试官喜欢问：**为什么MySQL索引用B+树，而不是二叉树、哈希表？**

我们逐个对比：

| 数据结构 | 查找复杂度 | 适合场景 | 不适合做索引的原因 |
|---------|-----------|---------|------------------|
| **二叉搜索树** | O(log n) | 内存查找 | 树太高，磁盘IO多 |
| **哈希表** | O(1) | 等值查找 | 不支持范围查询 |
| **B树** | O(log n) | 早期数据库 | 非叶子节点存数据，一次IO拿到的key少 |
| **B+树** | O(log n) | MySQL InnoDB | ✅ 叶子节点存数据，非叶子节点只存key |

> 💡 说白了：B+树就像一栋楼——电梯口（非叶子节点）只放楼层号，每间房（叶子节点）放真正的数据。电梯口越小，一层能放的楼层号越多，树就越矮，IO就越少。

---

### 三、B+树的关键特征

#### 3.1 非叶子节点只存key，不存数据

**好处**：非叶子节点只存key，一个页（16KB）能存更多key，树更矮，IO更少。

#### 3.2 叶子节点用双向链表连接

这是B+树和B树最大的区别——**B+树的叶子之间有指针，B树没有**。

**好处**：
- 范围查询极快：找到起点后，顺着链表往后扫就行
- 排序查询天然有序：ORDER BY不用额外排序

> 💡 说白了：B+树的叶子像一排人手拉手，找到第一个人，后面的跟着就出来了。B树呢？每找一个人都要重新回上一层找，效率差远了。

**面试必问**：
- B+树和B树有什么区别？
- 为什么MySQL用B+树而不是B树做索引？

---

**📝 面试解答**：

**Q: B+树和B树有什么区别？**

![image.png](https://developer.qcloudimg.com/http-save/yehe-7512475/653b5b6aeccee3c3dc6025483e30c94a.png)!

![image.png](https://developer.qcloudimg.com/http-save/yehe-7512475/a2e76ac19c0bf8e426a22d1588320f8e.png)

> 三个核心区别：
> - **非叶子节点**：B+树只存key，B树存key+数据 → B+树一个页能存更多key，树更矮
> - **叶子节点**：B+树所有数据都在叶子，B树数据分散在各层 → B+树查询稳定，都是O(log n)
> - **叶子链表**：B+树叶子之间有双向链表，B树没有 → B+树范围查询极快

**Q: 为什么MySQL用B+树而不是B树做索引？**

> 1. **IO更少**：B+树非叶子只存key，同样16KB的页能存更多key，树更矮，IO次数更少
> 2. **范围查询更快**：叶子之间有链表，找到起点后顺着扫就行；B树要中序遍历
> 3. **查询更稳定**：所有数据都在叶子节点，每次查询路径长度一样

---

### 四、InnoDB的索引结构

InnoDB有两种索引：**聚簇索引**和**二级索引**。

#### 4.1 聚簇索引（主键索引）

聚簇索引的叶子节点存的是**整行数据**。

![image.png](https://developer.qcloudimg.com/http-save/yehe-7512475/5668462b5759ef8b49bf3f09efb78d64.png)

> 💡 聚簇索引 = 数据本身。InnoDB的数据就是按主键顺序存的，所以**主键查询是最快的**。

#### 4.2 二级索引（非主键索引）

二级索引的叶子节点存的是**主键值**，不是整行数据。

![image.png](https://developer.qcloudimg.com/http-save/yehe-7512475/9333f6ebe9226d9e0dd48894107f183e.png)

查name='张三'，先用二级索引找到主键id=30，再回聚簇索引找整行数据——这个过程叫**回表**。

**面试必问**：
- 什么是聚簇索引？什么是二级索引？
- 什么是回表？

---

**📝 面试解答**：

**Q: 什么是聚簇索引？什么是二级索引？**

> - **聚簇索引**：叶子节点存整行数据，数据按主键顺序存储。一张表只有一个聚簇索引。
> - **二级索引**：叶子节点存主键值，查到主键后需要回聚簇索引取完整数据。

**Q: 什么是回表？**

> 通过二级索引找到主键值，再回聚簇索引查整行数据的过程叫**回表**。
>
> 回表意味着多一次B+树查找，所以二级索引比主键索引慢。
>
> 避免回表的方法：**覆盖索引**（后续章节讲）——让查询只需要走二级索引就能拿到所有需要的列。

---

## 实战案例

### 场景一：查看索引结构

```sql
-- 创建测试表及执行结果
CREATE TABLE t_index_demo (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50),
    age INT,
    INDEX idx_name (name)
) ENGINE=InnoDB;

-- 查看索引
SHOW INDEX FROM t_index_demo;
-- 结果：会看到两个索引
-- 1. PRIMARY（聚簇索引，列id）
-- 2. idx_name（二级索引，列name）

-- 用EXPLAIN观察索引使用
EXPLAIN SELECT * FROM t_index_demo WHERE id = 1;
-- type=const，走主键索引，最快

EXPLAIN SELECT * FROM t_index_demo WHERE name = '张三';
-- type=ref，走二级索引，需要回表
```

---

### 场景二：观察回表过程

```sql
-- 回表示例及执行结果
-- 只查主键，不需要回表
EXPLAIN SELECT id FROM t_index_demo WHERE name = '张三';
-- Extra: Using index → 覆盖索引，不回表！

-- 查所有列，需要回表
EXPLAIN SELECT * FROM t_index_demo WHERE name = '张三';
-- Extra: NULL 或 Using where 或留空 → 回表查询
```

> 💡 说白了：查 `id` 不回表（二级索引叶子就有），查 `*` 要回表（二级索引叶子没age等列）。

---

### 场景三：B+树的分裂

```sql
-- 顺序插入（主键自增，不分裂）
-- InnoDB主键自增时，B+树顺序追加，不会发生页分裂
INSERT INTO t_index_demo (name, age) VALUES ('张三', 25);
INSERT INTO t_index_demo (name, age) VALUES ('李四', 30);
-- ... 顺序插入，性能好

-- 乱序插入（可能触发页分裂）
-- 如果主键不是自增的，插入可能触发B+树的页分裂，导致性能下降
```

> 💡 这也是为什么主键推荐自增——顺序插入不会触发页分裂，性能最好。

---

## 避坑指南

> ⚠️ 真实踩过的坑：

1. **主键乱序导致页分裂**
   - 主键不是自增的（如UUID），插入时B+树频繁分裂
   - 建议用自增主键，顺序插入效率最高

2. **二级索引回表导致慢查询**
   - `SELECT *` 走二级索引必须回表，比主键索引慢
   - 能用覆盖索引就用覆盖索引，避免回表

3. **索引列数据太大影响B+树高度**
   - 索引列越短，一页存越多key，树越矮
   - VARCHAR(255)做索引比INT做索引，树更高更多IO

4. **混淆聚簇索引和二级索引**
   - 聚簇索引只有一张表一个，就是主键
   - 二级索引叶子存的是主键值，不是数据行指针

---

## 思考题

> 🤔 互动时间：

1. 为什么InnoDB表必须有主键？如果没有定义主键会发生什么？
2. 覆盖索引为什么不需要回表？

---

## 总结

> 🎯 **面试考点**

- B+树 vs B树：非叶子只存key、叶子有链表、查询稳定
- 聚簇索引：叶子存整行数据，按主键顺序存储
- 二级索引：叶子存主键值，需要回表
- 回表：二级索引→主键值→聚簇索引→整行数据
- 自增主键避免页分裂，性能最优

---

> 💡 **AI实战建议**：让自己的AI助手记住建表规范检查清单，每次写CREATE TABLE时自动检查：
> - 必须有主键，且推荐自增
> - 索引命名遵循规范：普通索引以 `idx_` 开头，唯一索引以 `uk_` 开头
> - 联合索引列数不超过5列

---

**下期预告**：索引优化：何时建索引、何时不建 —— 面试必问！
**全本合集**：[《每天一个MySQL知识点，百日打怪升级》](https://github.com/martianzhang/mysql_100_days)  您的关注是我每日更新的动力

---

*有问题欢迎评论区交流，明天见！*

做这个系列，源于一个朴素的愿望：把踩过的坑、总结的经验系统化输出，希望能帮到刚入行或想进阶的兄弟们。

【第5天】每天一个MySQL知识点，百日打怪升级

本文是MySQL索引核心篇，由10年经验DBA精讲B+树原理。深入剖析为何选B+树而非B树/二叉树/哈希表，详解其非叶节点仅存key、叶子双向链表、聚簇与二级索引结构，并结合回表、覆盖索引、页分裂等实战场景，直击面试高频考点。（239字）

数据库

职业发展

B+树是MySQL索引的核心数据结构，相比B树具有非叶子节点只存key、叶子节点双向链表连接等优势，能减少IO次数、提升范围查询效率。InnoDB采用聚簇索引和二级索引结构，主键索引存储完整数据，二级索引需回表查询。合理设计自增主键可避免B+树页分裂，提升性能。

数据结构

MySQL

腾讯云数据库特惠，新用户首单0.5折起


2026采购季 | AI焕新·智启新局

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【第5天】每天一个MySQL知识点，百日打怪升级-腾讯云开发者社区-腾讯云

【第5天】每天一个MySQL知识点，百日打怪升级

【第5天】每天一个MySQL知识点，百日打怪升级

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐