B+ 树索引碎片是怎么产生的？为什么需要重建或整理索引？
简化版
B+ 树索引碎片主要来自随机插入、删除、页分裂和页合并不充分。碎片会导致页利用率下降、扫描时读更多页、缓存效率变差。重建或整理索引可以重新排列页、提高填充率，但会带来额外 I/O 和锁/资源成本。
详细版
B+ 树叶子页按 key 有序，但物理页不一定连续。随着写入和删除：
- 随机插入可能触发页分裂，留下半满页；
- 删除记录后页内产生空洞；
- 页合并可能为了并发和成本并不立刻发生；
- 逻辑相邻页在磁盘上可能越来越分散。
后果包括：
- 同样数据需要更多页；
- 范围扫描读更多页；
- Buffer Pool 缓存命中变差；
- 统计信息和执行计划可能受影响。
索引重建会重新组织 B+ 树，整理页内空间和页顺序。是否需要重建，要看碎片程度、表大小、业务窗口和数据库具体机制。
完整版教学
一、什么叫 B+ 树索引碎片
索引碎片可以分成页内碎片和页间碎片。页内碎片指一个页里有很多空洞或填充率很低；页间碎片指逻辑上相邻的叶子页在物理存储上不连续，范围扫描时访问路径更跳。两者都会让同样的数据占用更多页，降低缓存和 I/O 效率。
B+ 树是动态结构，它会随着插入删除不断调整。只要数据不是一次性有序批量加载，长期运行后出现碎片很正常。
记忆钩子：B+ 树碎片不是树坏了，而是页越来越松、越来越散。
二、页分裂如何制造半满页
当某个叶子页满了，新记录又必须插入这个页范围，就会触发页分裂。常见策略是把原页一部分记录搬到新页，再把新页接入叶子链表。分裂后两个页可能都只有约一半满。
分裂前: [10 20 30 40 50 60] 满
插入35: [10 20 30] [35 40 50 60]如果后续插入均匀分布，空间可能慢慢被填满；如果数据分布变化或删除很多，半满页可能长期存在，导致页利用率偏低。
三、删除为什么不一定立刻合并页
删除记录后，页里会出现可复用空间。理论上页太空可以和兄弟页合并，但数据库不一定每次都立即合并。原因包括：合并要修改父节点和兄弟链，增加写放大；并发下合并需要更多 latch；刚合并后如果又插入，可能马上再分裂。
因此很多系统会延迟整理或只在阈值满足时做合并。这样能降低单次删除成本，但长期可能留下碎片。
四、碎片对查询有什么影响
碎片最直接影响范围扫描。假设原来 100 万条索引记录需要 2000 个页，碎片后需要 3500 个页，同样范围扫描要读取更多页。即使页在缓存中，也会占用更多 Buffer Pool 空间，挤出其他热点页。
| 影响 | 表现 |
|---|---|
| 页利用率下降 | 索引文件变大 |
| 页间不连续 | 范围扫描随机性增强 |
| 缓存效率降低 | 相同缓存容量容纳更少数据 |
| 写入维护增加 | 更多页、更多分裂机会 |
点查受影响可能没范围扫描明显，但缓存和树层级变化仍可能带来成本。
五、重建索引做了什么
重建索引通常会重新扫描数据并构造新的索引结构，让页按较好的填充率重新组织。它可以消除大量页内空洞，让逻辑顺序更紧凑，也可能更新统计信息。具体是否在线、是否阻塞写入、是否额外占空间，取决于数据库实现。
旧索引: 松散页 + 空洞 + 逻辑相邻物理分散
重建后: 更紧凑的叶子页 + 更合理的页分布但重建不是免费午餐。大表重建会消耗 CPU、I/O、日志空间，还可能影响复制延迟和业务性能。
六、如何减少碎片产生
如果主键或索引 key 单调递增，插入大多发生在右侧末尾，页分裂更可控；随机 UUID 作为主键会把插入打散到各处，更容易频繁分裂。填充因子也能预留空间，减少后续插入导致的分裂。
| 做法 | 作用 | 代价 |
|---|---|---|
| 使用趋势递增 key | 减少随机页分裂 | 可能有热点页 |
| 设置填充因子 | 给未来插入留空间 | 初始占用更多页 |
| 定期整理索引 | 恢复紧凑结构 | 维护窗口成本 |
| 避免无用索引 | 降低写维护 | 查询可能少一个路径 |
索引维护需要结合业务写入模式，不是所有表都要频繁重建。
七、常见误区与追问
- 误区：B+ 树会自动一直保持页满。 动态插入删除会产生半满页和空洞。
- 追问：随机主键为什么容易碎片？ 插入位置分散，容易在各个叶子页触发分裂。
- 误区：碎片只影响磁盘空间。 它还影响范围扫描、缓存效率和写入维护。
- 追问：重建索引一定安全吗？ 要考虑锁、I/O、日志、复制延迟和业务低峰窗口。
- 误区：删除后页一定立即合并。 立即合并成本高，很多系统会延迟或按阈值处理。
八、加强记忆
B+ 树碎片来自长期动态变化：插入导致分裂，删除留下空洞，合并和整理不一定立刻发生。碎片让页更松、更散，范围扫描和缓存效率都会受影响。重建索引能重新压实结构，但也很重。面试里把「产生原因、性能影响、治理成本」三步讲完整，比只说重建索引更靠谱。