为什么删除比插入更复杂

想象整理书柜：你先按书名目录找到位置，抽走它，回头发现那一层书架太空还得重新分发或合并。B-树删除一个关键字，整体就跑着「搜索—删除—修复」三段流程。

三次判断决定走哪条处理路径

上页决策树的第一步就是「目标在叶子节点」。这是所有情况里最轻松的一种，因为叶子没有孩子要照顾，删除只是从一段有序序列里去掉一个元素。

情况一我们搞定了叶子——直接删就行。但内部节点有左右子树，直接抽掉会让孩子节点悬空。这一页看怎么把它转成叶子再删。

三条路径做同一件事：找叶子里的键覆盖 k，再走叶子删除。差异只在「去哪儿找」。

用右子树最小节点替换原值，再在叶子层把它删掉，分四步走。

前几页我们解决了「删谁」的问题——叶子直接删，内部用后继替换。但真正把关键字拿走后，被波及的节点可能瞬间变薄。薄到什么程度算异常？这就是下溢。

上页讲到下溢是节点关键字数跌破下限。但根节点是个例外——它是树的'特殊公民'，可以比别的节点更少。这条豁免背后，藏着 B-树高度收缩的机制。

下溢发生后，合并并非唯一选择。当相邻兄弟还有富余时，旋转借一个就能补齐——这是处理下溢代价最小的路径。

图分两支：右旋向左兄弟借，左旋向右兄弟借。每条路径3步：父key下沉、兄弟key上移、兄弟子树挂载。

当删除后非根节点少于 B-树允许的最少关键码数，且相邻兄弟也没有多余关键码时，借位不再安全，只能把两片节点合成一片，再把父节点中的分隔关键码放下来。

决策入口先判能否旋转，否则进入合并；合并三步走，父节点下溢则递归向上。

从下溢出发,依次问左、右兄弟是否富余,能借则旋,不能借则合。

用流程图展示m=3 B-树删除叶子节点且不引发下溢的完整路径,重点观察keys数≥2这一安全判据。

流程图：跟踪一棵5阶B树删除键后，从下溢发生到左旋修复的完整步骤。

从叶子下溢开始，跟随流程看无法旋转时如何用合并修复B-树。

用后继节点替换并触发下溢修复的完整过程

沿主路径追踪合并后的连锁反应：从叶子一路传到根。

插入与删除的修复看似对称，实则方向相反——一页看清镜像关系

B-树删除时要旋转、合并、还可能一路向上连锁修复——这些操作并不便宜。为何不删完先放着，等下次查询时再顺手修？这关系到 B-树的核心设计哲学。

• ✓下溢修复首选旋转，旋转不行才合并
• ✓内部节点删除通过后继替换转为叶子删除
• ✓下溢可能沿路径向上连锁传播至根
• ✓删除是插入的镜像但更复杂

先独立思考三分钟，再对照参考答案看自己的思路是否命中要害。