结合此前我们围绕MySQL B+树索引展开的相关讨论，使用B+树存储的索引增删改查效率整体表现优异，是适配磁盘场景的最优索引结构之一：
查询效率
时间复杂度稳定为O(logₘN)，千万级数据下树高仅3层左右，单次等值查询仅需3次以内磁盘IO，范围查询可直接沿叶子节点链表遍历，无需回溯父节点，性能比B树提升40%以上。
插入效率
常规场景下仅在叶子节点完成写入，仅当节点键值数超过阶数阈值时触发分裂，通过50%均
分策略维持树平衡，批量导入时调整填充因子可让插入速度提升3-5倍。
删除效率
删除后若节点键值数低于阈值，仅通过从兄弟节点借值或合并节点完成维护，不会引发全树大规模调整，操作开销可控。
更新效率
若仅更新非索引字段，无需修改索引结构；若更新索引字段，仅需定位对应叶子节点完成修改，必要时触发节点分裂或合并，整体性能远优于二叉树类结构。
B+树索引缺点：
等值查询性能弱于哈希索引
相比哈希索引的O(1)等值查询效率，B+树等值查询需要遍历整棵树高，性能略逊一筹，在纯等值查询场景下没有优势。
额外占用物理存储空间
B+树的非叶子节点存储导航键值，加上叶子节点的有序链表指针，会产生额外的存储开销，数据量越大，索引占用的磁盘空间也会随之增加。
降低表的增删改效率
每次对数据执行增删改操作时，都需要动态维护B+树的结构，可能触发节点分裂、合并等平衡操作，数据量越大，维护耗时也会相应增加。
长字段索引场景性能骤降
如果索引字段长度过大，单节点能容纳的键值数量会大幅减少，直接导致树高显著增加，磁盘IO次数变多，查询延迟明显上升，完全不适合作为全文索引的底层结构。
