B+Tree索引原理与实现：从结构设计到数据库工程实践

1. 为什么数据库内核的索引选型会落在B+tree上

B+tree这个名字，搞数据库的人早晚得碰一次。CMU 15445 2025 fall的lec8整讲都在围绕这一个结构展开，原因很简单：它是大多数关系型数据库存储引擎的默认索引实现，也是你理解“数据库为什么不能只是把数据塞进文件里”的起点。

先说一个容易被忽略的事实：B+tree不是用来“存数据快”的，而是用来“在大量数据里找得准、找得快、还能按顺序扫”的。MySQL的InnoDB索引、PostgreSQL的默认索引、SQLite的默认索引，底层都是B+tree的变体。你要是能把B+tree的原理和实现吃透，等于同时看懂了好几款主流数据库的索引骨架。

这门课适合谁？适合正在学数据库系统、准备做内核相关开发、或者工作中要调SQL性能但一直停留在“索引就是加速查询”这种模糊认知的人。lec8的内容不会手把手教你背定义，它更核心的命题是：当你面对一个真实存储引擎时，B+tree的每个设计决策到底在解决什么问题。

1.1 磁盘与内存的差异决定了数据结构的选择

学B+tree之前，必须先理解一个背景：数据库的数据量远大于内存，索引必须落盘。而磁盘随机读写的代价，比内存访问高好几个数量级。粗略来说，内存随机访问是纳秒级，SSD随机读是微秒到毫秒级，机械盘更是几十毫秒级别。哪怕现代系统加了很多缓存，索引树的每个节点仍然要被当作“一页”来读取，这就意味着树的高度直接决定了查询要触发多少次磁盘IO。

设计索引时要做的第一件事，就是让树“矮”。二叉树在数据量大的时候会高得离谱，几十亿条记录大概要30多层，每一层都可能是一次磁盘随机IO，这在实际工程里是灾难。B+tree的做法是一个节点塞很多key，让每个节点占据一个页，一次IO拉回一整块有效数据。这就是为什么B+tree的高度通常只有3到4层，几亿条数据的索引也能稳稳压在这个区间内。

读者可能想问：既然节点里塞那么多key，内存里的比较成本不是变高了吗？对，但这是值得的——内存内的二分/线性比较再慢，也比一次磁盘IO快好几个数量级。空间换时间，本质上是用CPU的廉价计算去换磁盘的昂贵IO。

1.2 从两次寻道到三次IO：理论上的最优区间

我记得第一次做完B+tree实现后有个很直观的感受：一棵4层的B+tree，点查询最多也就碰4个节点，而root节点大概率一直在缓冲池里，所以真实情况下多数查询只需要2到3次节点访问。这个数量级，比“从几百万行里扫一遍”要友好太多太多了。

另外还有一个常被忽视的点：B+tree在叶子节点上把所有数据按key排序串成一个链表，这让范围查询可以直接线性扫描，而不是中序遍历整棵树。很多业务查询本质上都是范围扫描，比如“查最近7天的订单”“查某段时间的日志”，这类需求如果换成哈希索引，就需要把所有候选key全部算一遍再排序，性能完全不是一个量级。

所以从整个存储引擎的角度看，B+tree解决的是两个核心诉求：单点查询要快，范围查询也要快，同时在数据量增长时性能退化是平缓的。二叉搜索树单点可以快，但范围不友好；哈希索引单点极快，但范围是废的；LSM树写放大更低，但读放大和空间放大需要额外机制去补偿。B+tree的均衡态，在通用事务型负载下确实是最稳的选择之一。lec8其实也在不断传递这个观点：不要死记B+tree的结构图，要带着“为什么要这样设计”的视角去看每个细节。

2. 先把B+tree的结构定义掰开揉碎

如果只记一句话，B+tree就是一棵多路平衡搜索树，内部节点只存key和指针，不存实际数据，实际数据全部存在叶子节点，并且叶子节点之间通过双向或单向链表串起来。这个结构在课程里被称为B+tree，区别于经典B-tree。B-tree的内部节点可以直接存数据，B+tree却把数据专门留给叶子层，这个差异带来一个非常实际的收益：内部节点在同样的页大小下能塞下更多key，树的高度因此更矮。

lec8里用的定义是：一个节点最多能容纳n个key和n+1个child pointer（内部节点），叶子节点最多能容纳n个key-value pair。n通常由页大小除以单个key/指针大小得出。CMU 15445的project里，你是在一个Page大小的数组里做二分查找，这个数组上限通常就是几百个key。所以要抛弃“每个节点只存几个key”的印象，尽量把节点想象成一个容量数百的紧凑数组。

2.1 每个节点到底存了什么

内部节点的物理结构大致是这样的：一个header记录节点类型、当前key数量、兄弟指针等元信息；紧跟着是一块连续的key数组；再往下是一块连续的child page id数组（或者按课程project里的实现，是指针数组）。注意，这里不像某些教科书那样交错存放，而是先存key再存pointer，这样硬件缓冲区和CPU缓存更友好。

叶子节点则更简单，它存key和对应的record id或tuple指针。在课程project里，叶子节点存的是key加上value，value要么是实际记录在堆文件中的位置，要么是记录本身，取决于你的实现。这个“value到底是什么”会影响后续所有操作设计，我建议在动手前先想清楚：你的value是定长的page id+slot number，还是变长的数据？这决定你写split和merge时要memcpy多大一块内容。

还有一个细节得提醒：B+tree内部节点里存的key，本质是“路由key”，不一定要和叶子里的key一致。很多实现会为了省空间，在内部节点里存子树的最小key或最大key作为边界，但不强制要求内部key也出现在叶子节点中。这个设计自由度，在做delete的borrow时特别容易踩坑，后面会详细说。

2.2 一个容易被新手忽略的边界：key数量与child数量的关系

很多第一次写B+tree的同学会在这个地方翻车：内部节点的child数量始终比key数量大1。假如一个内部节点有3个key，它应该指向4个孩子，两个相邻key之间是一个孩子区间，最小的key左边还有一个孩子，最大的key右边还有一个孩子。这个语义决定了你从根节点往下搜索时，每一步都是“先比较，再选择一个孩子”。

举个例子，内部节点key为[10, 20, 30]，则四个孩子分别对应：<10、[10,20)、[20,30)、≥30（区间开闭看具体实现）。搜索key=25时，应该走第三个孩子。如果用二分查找，找到“最后一个小于等于target的key”，然后取它的下一个child pointer即可。

叶子节点则没有这个烦恼，它就是纯key-value列表。这个“内部节点child比key多1”的约束在实现插入和删除时，会引发一系列连锁反应：插入导致节点满了要分裂，分裂后中间key要上升到父节点，同时父节点也会因此多一个child；删除导致节点少于半满要合并或借key。所有的复杂逻辑，根源都是这个key-count和child-count的强约束。

2.3 变长key怎么办：课程里的工程化取舍

理论上B+tree的key可以是任意可比较类型，但实际存储时，如果key是变长字符串，直接内嵌在节点里会有两个麻烦：一是节点内空间无法预分配，二是memeff复制开销不可控。课程project的简化版本里，很多时候直接假设key是定长的（比如8字节整数或定长字符数组）。如果你要做变长key，工程上常见的做法是：节点里存key的固定长度前缀或哈希，完整内容放单独的存储区。不过lec8的scope主要还是定长key，先把核心算法跑通再说。

我自己做实现时用的就是8字节int64作为key，理由有三个：省去变长分配逻辑、二分查找可以直接算偏移、调试时打印节点内容一目了然。等B+tree核心逻辑稳定之后再考虑泛型化，会少掉很多痛苦。如果你正好也要刷这个project，强烈建议先从定长key起步。

3. search / insert / delete 全流程拆解

lec8花了大量篇幅讲B+tree的三个核心操作：search、insert、delete。这三个操作听起来简单，但每个都有不少细节，尤其是插入和删除涉及的分裂与合并，难度陡增。下面我按实现时的思考顺序，把所有流程拆一遍。

3.1 点查询和范围查询

点查询的流程可以概括为“从根开始，逐层向下”，直到叶子节点。叶子节点内部用二分查找或线性扫描找到key对应的value。代码逻辑大约是这个样子：

python复制def search(root, target):
    node = root
    while not node.is_leaf():
        # 找到最后一个 <= target 的 key 对应的 child
        idx = node.get_child_index(target)
        node = node.get_child(idx)
    # 到达叶子节点
    return node.lookup(target)

这个流程里最关键的是child index选择。如果你用“最后一个key ≤ target”的语义，那么返回的child是idx+1；如果你用“第一个key ≥ target”，那么返回的是idx。无论哪一种，一定要和自己的插入分裂逻辑保持一致，否则根节点分裂后，整棵树的搜索会随机丢key。

范围查询是在点查询基础上的扩展：先找到左边界对应的叶子节点位置，然后沿着叶子的next指针向后扫，直到超过右边界。很多实现会把叶子节点做成双向链表，有的还会把每个叶子上的最大值直接存在header里，这样判断“是否超出范围”时能少访问一次叶子节点。

实际跑测试时，我见过不少同学在点查询上得分不错，但范围查询全挂。原因多半是split后忘记正确维护叶子链表的next/prev指针，或者是边界条件选错导致范围查询多扫了一个空叶子。这属于“实现时没留意，调试时火葬场”的典型案例。

3.2 插入：先找叶子，再处理分裂

插入的流程是一个递归下沉的过程：从根一路走到叶子，把key-value插入到合适的位置。如果插入后叶子未满，万事大吉；如果叶子满了，就要分裂。

叶子分裂的标准做法是：把原有元素和待插入元素合并成一个临时数组，找到正中间的位置，左边一半留在原节点，右边一半移到新节点，然后把中间分隔key上升到父节点。关键点在于：叶子节点上升的，往往是“右半区第一个key”，而不是临时数组的平均值。这个key会作为父节点中区分两个叶子的路由信息。

内部节点分裂稍微不同：内部节点满了之后，同样合并出一个临时数组，但中间key不留在任何一个子节点里，而是被“提”到父节点。为什么？因为内部节点的child数总是比key数大1，如果把中间key留在某个孩子里，会导致两个孩子的key数量和child数量失衡。这是B+tree和普通B-tree在分裂逻辑上最大的区别：B-tree分裂后中间key可以直接留在当前节点中，B+tree则必须把key上提，腾出一个空位给新的child pointer。

整个向下插入过程中，一个常用的策略是“先分裂再向下”，也就是在搜索路径上，只要碰到满节点就先分裂掉。这样能保证“向下递归到叶子时，父节点一定有空间接受上升的key”。这种写法的好处是你不需要在递归返回时再处理父节点满的情况，逻辑更简单。

不过也有人用“先向下插入，返回时处理分裂”的写法，这两种思路各有利弊。我个人的经验是：先用“向下时提前分裂满节点”的方式跑通整个流程，因为它在代码里更容易保证父节点永远有位置，后续排查bug时心智负担小很多。

3.3 删除：合并与借key的平衡逻辑

删除比插入更麻烦，因为节点少到一定程度时需要触发“再平衡”操作。课程criterion里通常这样定义：一个节点如果少于半满，就需要处理underflow。具体是“少于ceil(n/2)个key”还是“少于n/2个key”，每个实现定义不同，建议先明确自己的阈值再动手。

underflow处理有两种手段：向兄弟节点借一个key（redistribute），或者和兄弟节点合并（merge）。优先尝试借key，因为借key不需要改变父节点中的路由指针数量，只需要在两个节点之间搬一个元素并更新父节点中对应的分隔key。如果两个兄弟节点都是半满，合并不太亏，那就可以合并：把两个节点的key合并到一起，同时删除父节点中对应的路由key和child指针。

这里很容易踩的一个坑是：合并后父节点的key数量减少，可能让父节点也underflow，所以删除是一个递归过程，可能要一路向上处理到根节点。如果根节点最后只剩下一个child，这个根节点就该被销毁，树的高度减一。这个逻辑如果只在叶子层做、不递归回内部节点，跑常规测试可能看不出问题，但一旦触发多层underflow，就会报“key丢失”或“找不到叶子”这类错误。

另外还有个小技巧：删除时先尝试从右兄弟借key，右侧不行再试左侧，这样你可以只维护一个方向上的“兄弟指针”逻辑。虽然双向链表可以两边都查，但先固定一个方向能让代码少很多分支。lec8里也强调，删除了数据不等于物理空间立刻释放，节点可以保留半空状态，只在低于阈值时才做重平衡，这个“懒删除”策略本身也是一个性能优化点。

4. 实现B+tree最容易踩的五个坑

我把这轮做B+tree实现时踩过的坑全部列出来，都是调了很长时间才发现原因的问题。提前看到这些，也许能帮你省下很多不必要的debug时间。

4.1 根节点分裂之后高度没有增加

根节点是一个特殊的节点：其他节点满了可以分裂并上升key给父节点，但根节点没有父节点。所以根节点分裂的时候，必须新建一个root，这个root里只有两个key（或一个key加两个child），然后把原root和新的右兄弟挂上去。这样树的高度从1变成2。

很多人写到这里会漏掉一个判断：只有当当前节点是root时，才会走“新建根节点”的逻辑；如果不是root，才把key上升到父节点。如果判断条件写错，后果就是根节点分裂后高度不变，整棵树的搜索路径错乱。

我建议在实现中单独封装一个函数负责“分裂节点并返回上升的key和新节点page id”，在调用处判断当前节点是否为root。判断的最好时机是：你在递归函数里刚读出一个node时，就顺便判断它是不是当前树的root，而不是在分裂完成后再判断。

4.2 分裂时中间key的去向

B+tree分裂最容易出错的点就是：中间key到底是留在左节点、右节点，还是上提给父节点。答案取决于你分裂的是叶子还是内部节点：

• 叶子分裂：中间key留在右节点中，同时把一个副本（通常是右节点的最小key）上提给父节点。
• 内部节点分裂：中间key不上提到任何一个孩子，直接上提给父节点。

很多第一次实现的人会在这两个场景里弄混：把叶子分裂当成内部节点分裂，导致叶子节点缺失了一个key；或者把内部节点分裂当成叶子分裂，导致父节点存储的边界key和孩子的实际key区间对不上。

我的建议是：在代码里明确区分两类分裂函数，不要在同一个函数里用if-else硬凑。叶子分裂函数里做的是“把右侧第一个key上提父节点”，内部节点分裂函数里做的是“把中间key上提父节点”。这两个语义虽然都叫split，但具体动作完全不同。

4.3 删除时兄弟节点选择与merge边界

删除时underflow了，选择哪个兄弟节点也有讲究。如果你的叶子/内部节点使用双向链表，通常可以优先找右兄弟；如果右兄弟也少于半满，就合并；如果右兄弟有多余的key，就借。这个策略虽然简单，但在边界条件下尤其要注意：最右侧的节点没有右兄弟，这时候必须去借左兄弟的key。

合并的时候还有一个非常隐蔽的坑：把右兄弟合并到左节点后，父节点中原本分隔这两个子节点的key应该“下沉”到合并后的节点里，然后删除父节点中对应的那个key和child指针。很多实现会忽略“key下沉”这一步，导致合并后父节点里残留一个不再有意义的key。虽然系统运行时间短可能暴露不出来，但一旦后续再发生分裂或删除，这个残留key会让二分查找进入错误的孩子区间。

4.4 递归实现中的返回值设计

如果你用递归来实现insert/delete，递归函数的返回值设计直接决定了代码的复杂度。最常见的两种设计：

• 返回“操作是否导致当前节点需要分裂/合并”，然后由上层调用处理。
• 返回“新的child节点指针（可能为NULL，表示无变化）”。

我建议用第二种：递归insert返回一个“向上层传递的新节点指针”，上层发现返回值不为NULL，就把这个新节点挂到自己的child数组里。这个设计的优点是不需要额外维护分裂标志位，逻辑集中在“是否新增了一个child”这一个维度上。

delete的递归返回值则更复杂一些，你可能需要返回“是否删除了一个child”，同时还要传递“当前节点key数量是否少于阈值”的状态。这时候我倾向于用一个小结构体或者tuple打包返回，而不是用多个out参数。否则调试时你会被各种引用参数搞得头大。

4.5 重复key与NULL指针问题

B+tree在理论上默认key唯一，但实际业务里经常有重复key。很多入门实现为了省事，直接假设没有重复场景。可一旦测试用例里出现重复，二分查找就会选出错误的插入位置，导致后续查询要么找不到、要么找到第一个就停了。

从课程project的角度看，通常要求支持重复key，但具体允许的方式有几种：一种是把重复key的多个value都放在同一个叶子节点里，另一种是每个key后挂一个链表。最简单的做法是把value设计成“可以存多个值的list”，或者在叶子节点内部允许同key多值但顺序排列。这样在插入时，如果key已存在，直接追加到该key的value列表中即可。删除也一样，先删除单个value，如果这个key的value列表空了对整个key做删除。

NULL指针问题则多半出现在“空树”或“只有一个根节点”的边界场景。空树时root指针必须是NULL而不是一个空节点，很多实现初始化时new了一个空节点当root，结果后续查找时就永远进不到“根就是叶子”的分支。我建议初始化时root直接置为NULL，插入第一个key时再去创建真正的root叶子节点。

5. project里的工程细节与优化思路

lec8不仅是理论讲解，CMU 15445配套的project则更偏工程落地。很多同学刷到B+tree那一关时会觉得“算法都明白，但代码调不通”，根本原因是缺少对存储层物理结构的了解。下面结合我在project中实际踩过的细节，聊聊工程实现时不能忽略的部分。

5.1 节点就是page：物理存储结构

在CMU 15445的project规格里，B+tree的每个节点会被序列化到一个Page里。Page的大小通常是4KB或8KB（默认配置下常见的是4KB）。这意味着你在一个节点里能放多少个key，不是由算法决定的，而是由Page大小除以key和指针大小决定的。比如8字节key加4字节页ID，4KB节点大概能放300多个key，具体的maxSize在你初始化空节点时就要算清楚。

正因为节点是Page，所以你要时刻注意：内存里的struct和你写回磁盘的字节流必须一致，否则下一次读回来数据就全乱了。常见做法是定义一个紧凑的节点header，后面跟一个连续key数组、一个连续指针数组，通过偏移量来访问，而不是直接塞一个C++的std::vector到Page里。很多人在这上面踩坑，就是因为vector的内存布局不是连续的、还需要堆分配，序列化到Page后直接崩。

Leaf节点里存value的方式也有讲究。如果是存record id，那value就是固定大小，轻松搞成连续数组；如果是存变长大字段，那就要考虑溢出页。作为入门实现，先别做变长value，老老实实存定长record id或page id。

5.2 关于prefix compression和变长key

lec8结尾通常会提一些优化，比如prefix compression、suffix truncation、fingerprint path hint等。这些算是进阶内容，但值得了解一下，因为面试时经常会被问。

prefix compression的思路是：相邻两个key之间的公共前缀很长（比如一堆字符串都指向同一张表），那就只在节点里存公共前缀的差量部分，减少空间占用。这能提升节点容量，但代价是插入和删除时要维护公共前缀的变化，代码复杂度直接上一个台阶。

我在实际工作中很少在课程project里实现它，但会在脑子里掌握它的优缺点，因为它对理解“B+tree为什么能撑住海量索引”很有帮助。如果你想让project更有竞争力，可以尝试实现一个简单的prefix compression，你会发现它对范围查询和插入性能的影响特别有意思。

5.3 并发控制：先留个预告

lec8篇幅有限，通常不会讲B+tree的并发控制细节，那一般会在后面独立成课。不过动手做project时，早晚会遇到“多个线程同时读写B+tree”的需求。这里先做个预告，后面细啃并发时会用到几个关键词：latches、optimistic locking、latch crabbing/coupling。核心思想是：加锁不是加在整棵树上，而是沿着搜索路径“一进一出”地携带锁，提高并发度。

如果你现在正在写单线程版的B+tree，建议先把逻辑跑通，再考虑并发。不要一上来就加锁，否则并发问题会掩盖算法本身的bug——那调试难度是单线程的好几倍。等单线程全绿了，再引入latch机制去处理并发。

6. 常见问题速查表

这个表是我做调试的时候实际列出来的，虽然看起来很简，但每条背后都可能对应一整晚的debug时间。拿到project代码后，建议先把这几个场景的测试用例写掉，再开始系统刷分，效率会高很多。

个人在B+tree上踩了无数次坑之后的体会是：先把结构定义和边界条件写清楚，再动算法逻辑，顺序千万不能反。B+tree的代码量不大，难就难在状态太多了。真要把分裂、合并、借key这些逻辑一次性写对，几乎不可能，完全需要通过小规模随机测试来不断逼近正确性。准备一个能打印整棵树结构的调试函数，比什么都强，因为它能让你直观地看到每个key落到了哪个节点，也就能快速定位二分查找和child指针的问题。最后提醒一句：这门课的精髓不是背结论，而是亲手把B+tree从零写出来，再回头看lec8的课件，你会有一种“原来设计得这么巧妙”的豁然感。