MySQL B+ Tree 机制与算法详解

Wed, 29 Apr 2026 00:00:00 +0800

为什么数据库普遍选择 B+ Tree

如果只从算法课本看，查找一个有序集合有很多选择：数组可以二分，哈希表可以做到平均 O(1)，红黑树、AVL 树可以做到 O(logN)。但数据库的核心问题不是“CPU 内存里怎么找”，而是“磁盘或 SSD 上的数据怎么少读几次”。

MySQL 的 InnoDB 存储引擎把表数据和索引组织成页。默认情况下，一个页通常是 16KB。一次查询如果每深入一层索引就需要读取一个页，那么树的高度越低，I/O 次数就越少。B+ Tree 的核心优势就在这里：

每个节点能存放很多 key，树的分叉数很大，高度很低。
所有真实记录都在叶子节点，非叶子节点只负责导航。
叶子节点之间按 key 顺序连接，非常适合范围查询和排序扫描。
节点大小天然适合数据库页，可以和磁盘读写单位对齐。

所以，B+ Tree 不是为了在理论复杂度上压倒所有结构，而是为了适配数据库最昂贵的资源：随机 I/O。

从二叉树到 B+ Tree

普通二叉搜索树每个节点最多两个孩子。即使它保持平衡，一千万条数据的高度也大约是二十多层。放在内存里问题不大，放在数据库里就意味着一次查找可能触发很多次随机页读取。

B Tree 和 B+ Tree 解决的是“分叉太少”的问题。一个节点可以保存多个 key 和多个孩子指针。例如节点中有这些分隔 key：

[10 | 20 | 30]

它可以把搜索空间分成四段：

(-∞, 10) [10, 20) [20, 30) [30, +∞)

这样，一个节点不是二选一，而是多路分发。只要一个页中能放下足够多的 key 和指针，树的高度就会非常低。

B+ Tree 相比 B Tree 又进一步做了一个重要取舍：非叶子节点不存放完整数据记录，只存放用于导航的 key 和子节点页号；所有完整记录都放在叶子节点。这样非叶子节点更小，能容纳更多 key，树也就更矮。

B+ Tree 的基本结构

一棵典型 B+ Tree 可以分成三类节点：

MySQL 各个模块与核心机制：从一条 SQL 理解数据库原理

Tue, 28 Apr 2026 18:05:26 +0800

MySQL 是最常见的关系型数据库之一。很多人一开始使用 MySQL，关注的是如何写 SELECT、INSERT、UPDATE、DELETE，但如果想进一步理解性能优化、事务一致性、主从复制、锁等待、索引失效等问题，就需要了解 MySQL 内部由哪些模块组成，以及这些模块之间如何协作。

本文会以科普的方式讲解 MySQL 的整体架构、核心模块和重要机制。你不需要先成为数据库内核开发者，也可以建立一套清晰的理解框架。

1. MySQL 的整体架构

可以把 MySQL 大致分成两层：

客户端
 |
连接层
 |
SQL 层：解析器、预处理器、优化器、执行器、权限检查、函数、视图、触发器等
 |
存储引擎层：InnoDB、MyISAM、Memory 等
 |
磁盘文件与操作系统

其中最重要的设计点是：MySQL 的 SQL 层和存储引擎层是分离的。

SQL 层负责理解 SQL、检查权限、生成执行计划、调用存储引擎接口。存储引擎层负责真正的数据读写、索引组织、事务、锁、崩溃恢复等底层工作。

这也是为什么 MySQL 可以支持不同存储引擎。最常用的是 InnoDB，它是现代 MySQL 默认存储引擎，支持事务、行级锁、MVCC、崩溃恢复等关键能力。

2. 连接层：客户端如何连上 MySQL

当应用程序连接 MySQL 时，首先经过连接层。

连接层主要负责：

建立连接
认证用户名和密码
检查客户端权限
维护连接状态
处理连接线程
管理连接超时

常见连接方式包括 TCP 连接和 Unix Socket 连接。

例如应用程序使用如下连接信息：

host=127.0.0.1
port=3306
user=app_user
password=******
database=app_db

MySQL 会先验证账号密码，再根据权限表判断用户是否有访问某个库、表、列或执行某类操作的权限。