autumn-recruitment/02.MySQL/index/B+树索引原理_test.md

---
tags: [test/review, mysql, bplus-tree, clustered-index, secondary-index]
create time: 2026-08-09 12:00
---

# B+树索引原理_测试题

## 概述

本测试涵盖 InnoDB B+树索引的核心概念，包括 B 树与 B+树的本质差异、页分裂/合并机制、聚簇索引与非聚簇索引的区别，以及联合索引设计原则。共 10 道题：6 道选择题、3 道填空题、1 道简答题。

---

## 一、选择题（6道，由浅入深）

> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景

### Q1（基础）— 考察定义层面

InnoDB 存储引擎默认使用的索引数据结构是什么？

A. 哈希表
B. B+树
C. 红黑树
D. 跳表

### Q2（基础）→ 考察行为差异

以下关于 B 树和 B+树的说法中，正确的是哪一项？

A. B 树的非叶子节点也存储数据记录
B. B+树的查询路径长度不一致，取决于数据位置
C. B 树的叶子节点通过链表连接，支持高效范围查询
D. B+树在同样大小的页中能容纳更多键，因此树更高

### Q3（进阶）→ 考察原理理解

假设一个 InnoDB 表的页大小为 16KB，每条索引记录约 1KB，则单个页大约能容纳多少条索引键？在此条件下，1 亿行数据的 B+树高度通常是多少层？

A. 约 16 条，树高 5~6 层
B. 约 16384 条，树高 3~4 层
C. 约 1024 条，树高 4~5 层
D. 约 100 条，树高 6~7 层

### Q4（进阶）→ 考察比较辨析

为什么推荐使用自增 BIGINT 而非 UUID 作为主键？以下解释最准确的是：

A. UUID 太长，导致 InnoDB 无法为其建立索引
B. 所有二级索引叶子节点都存储了主键值，UUID 乱序插入会导致频繁页分裂且二级索引体积庞大
C. UUID 不唯一，可能产生主键冲突
D. 自增主键的查询速度是 UUID 的两倍以上

### Q5（深入）→ 考察场景推理

某业务表的主键为自增 BIGINT，当前填充率已达 85%。此时大量并发 INSERT 导致的页分裂策略是：

A. 每次都是严格的二分平分
B. 首次分裂占 7/8，后续改为平分，以预留碎片空间
C. 只有根节点满时才向上分裂，子节点不会立即分裂
D. 先删除旧数据再合并，避免产生碎片

### Q6（深入）→ 考察源码级细节

在二级索引的叶子节点中，实际存储的内容是：

A. 完整行数据
B. 索引列的值 + 回滚指针（rollback pointer）
C. 索引列的值 + 主键值
D. 索引列的值 + 该行的物理磁盘地址

---

## 二、填空题（3道）

### F1 — 聚簇索引的定义

InnoDB 中被称为"聚簇索引"的实际上是______索引，也就是说数据和索引存储在同一个______中。一张表有且仅有______个聚簇索引。

> **提示**: 聚簇的含义指的是数据文件本身就是按 B+Tree 组织的一份索引结构，想一想哪个索引直接包含了整行数据。

### F2 — 页分裂规则

当父节点也已满时，页分裂会______向上进行，直到找到不满的父节点或到达根节点。如果根节点发生分裂，则树的______会增加 1。

> **提示**: 分裂是从叶子节点向上传递的，根节点分裂是树结构变化的一个重要标志。

### F3 — 联合索引设计

在设计复合索引 `(col1, col2, col3)` 时，区分度高的列应放在______；等值查询列应在范围查询列之______；若 `WHERE col1 = 'a' AND col2 > 10 AND col3 = 'b'`，则只有前______列能有效利用索引过滤。

> **提示**: 回忆最左前缀原则和范围查询断链陷阱——遇到范围查询时，后面的列就无法使用前缀匹配了。

---

## 三、简答题（1道）

### S1

某电商订单表 `orders` 有以下字段：`id`（BIGINT 自增主键）、`user_id`、`status`、`created_at`、`amount`。现有以下两个高频查询：

```sql
-- 查询 1：按用户查订单列表
SELECT id, status, created_at FROM orders WHERE user_id = 100 ORDER BY created_at DESC;

-- 查询 2：统计各状态的订单总数
SELECT status, COUNT(*) FROM orders GROUP BY status;
```

请综合分析：
1. 为这两个查询分别设计索引方案
2. 解释为什么要这样设计（考虑区分度、最左前缀、覆盖索引等因素）
3. 说明这种设计对 INSERT/UPDATE 操作可能带来的影响

> **答题框架提示**: 先分析每个查询的过滤条件和排序需求 → 判断哪些列适合做联合索引 → 评估是否覆盖所有 SELECT 列 → 考虑索引维护成本。

---

## 参考答案与解析

### 选择题答案

| 题号 | 正确答案 | 解析 |
|------|---------|------|
| Q1 | B | InnoDB 的默认索引结构是 B+树。哈希表不支持范围查询；红黑树是多路平衡树但在磁盘 IO 场景下不如多路树高效；跳表主要用于内存场景。 |
| Q2 | A | B 树的每个节点都存储数据和键，而 B+树的非叶子节点只存键不做数据负担，所以 A 正确。B 错误因为 B+树所有查询路径等长；C 错误因为 B 树叶节点没有链表连接；D 错误因为 B+树同样数据量下树更矮而非更高。 |
| Q3 | B | 16KB / 1KB ≈ 16 条是错误的估算方式——实际上索引键通常远小于 1KB，加上指向子节点的指针后每页可放下约 16000+ 个键。以每页约 1000~2000 个键计算，1 亿行数据的树高通常在 3~4 层。 |
| Q4 | B | 核心原因有二：① UUID 长度 36 字节，远大于 BIGINT 的 8 字节，导致所有二级索引体积膨胀，内存缓存命中率下降；② UUID 随机性导致插入顺序无序，引发频繁的页分裂和碎片。A 错在 InnoDB 可以为 UUID 建索引；C 错在 UUID 设计保证全局唯一；D 无依据。 |
| Q5 | B | InnoDB 采用"首次分裂占 7/8，后续平分"的策略来预留碎片空间，避免频繁分裂。这是面试常考的优化细节。A 错在不是严格二分；C、D 描述的策略不存在于 InnoDB 实现中。 |
| Q6 | C | 二级索引叶子节点存储的是（索引列的值 + 主键值），通过主键可以回表到聚簇索引获取完整行。A 是聚簇索引叶子节点的内容；B 中的回滚指针用于 MVCC，不在二级索引中体现；D 的物理磁盘地址 InnoDB 不暴露给存储引擎外部。 |

### 填空题答案

| 题号 | 答案 | 解析 |
|------|------|------|
| F1 | 主键（或"聚簇"）；数据文件（或"InnoDB 表"）；1 | 聚簇索引的特点是数据文件和索引文件是同一份，叶子节点存储整行完整数据，每张表只能有一个聚簇索引。 |
| F2 | 递归；高度 | 父节点满了要递归向上分裂，这是 B+树的经典再平衡操作。根节点分裂意味着需要新增一层，树高度 +1。 |
| F3 | 前面；前；2 | 区分度高的列在前可以更早缩小查找范围；等值查询在前避免被范围查询中断最左前缀；`col1 = 'a'` 等值命中，`col2 > 10` 范围命中，但 `col3` 因 `col2` 的范围查询断链而无法使用索引。 |

### 简答题参考答案

**S1 参考答案要点**：

1. **查询 1 索引**：建议建立联合索引 `(user_id, created_at)`。`user_id` 是高区分度的等值过滤列，放前面可以快速定位；`created_at` 放后面可以直接满足 `ORDER BY` 排序需求，避免 filesort。同时 `id` 和 `status` 隐含在主键中，不需要额外覆盖。

2. **查询 2 索引**：建议建立 `(status)` 单列索引。`GROUP BY status` 可以利用索引的顺序分组，减少临时表的使用。虽然 `COUNT(*)` 需要从主键获取，但由于状态数通常很少（如待支付、已发货、已完成等），回表开销很小，不值得为这个查询单独建立覆盖索引。

3. **INSERT/UPDATE 影响**：增加索引会提高写入成本。每个 INSERT 需要在所有索引的 B+树中插入记录，可能导致页分裂。尤其是 `(user_id, created_at)` 联合索引，当 `created_at` 无序时也会触发分裂。可通过预排序批量插入或使用自增 ID + 顺序插入来缓解。

**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点（索引设计 × 2 + 原因分析 × 1 + 写入影响 × 1）。

## 关联笔记
- [[02.MySQL/index/B+树索引原理]]