Mysql，使用B+树存储的索引增删改查效率（七）

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