10｜数据库索引：为什么MySQL用B+树而不用B树？
该思维导图由 AI 生成，仅供参考
前置知识
B+ 树
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
数据库索引是数据库中非常重要的一部分，本文深入探讨了数据库索引的基本原理和B+树的优势。B+树作为一种多叉树，具有较低的高度、适合范围查询和非叶子节点不存放数据等优势。文章还介绍了索引的分类，包括聚簇索引、非聚簇索引和覆盖索引等。强调了设计覆盖索引以提高查询性能的重要性。此外，还探讨了索引的代价和面试准备中的相关策略。文章通过口诀和基本思路，引导读者了解数据库索引的基本原理和B+树的优势，以及索引的分类和优化方法。文章还深入讨论了MySQL为何使用B+树而不是B树，以及其他数据结构在数据库索引中的适用性。整体而言，本文为读者提供了全面的数据库索引知识，帮助他们快速了解和掌握相关技术要点。
《后端工程师的高阶面经》，新⼈⾸单¥59
全部留言(12)
- 最新
- 精选
子休关于索引列区分度的问题，这里稍微补充一个例子。 其实也未必所有区分度不高的索引都不会生效，比如一个列里面只有0和1两种值，看上去似乎区分度不高，但是如果0和1的值比例完全失衡，比如是95:5的比例，那么这种索引也有可能是生效。 比如一般的任务表里面，状态字段绝大多数都是“success”，少部分是“failed”，如果你查询的是失败的记录，这个时候状态字段的索引就可以生效了。作者回复: 是的，就是这种索引用起来效果不太好，因为区分度太低了。当然，如果你主要查询都是查 failed 的，那么就还挺好用的。
2023-07-18归属地：上海9
死者苏生https://zhuanlan.zhihu.com/p/519658576 mongodb用的wiredTiger就是B+树，建议这篇修改下，不要误人子弟作者回复: 感谢指正，我重新写一下相关论述。
2023-07-09归属地：河南38
长脖子树Mongo用的就是B+树作者回复: 感谢指正，我调整一下！
2023-07-09归属地：浙江34
徐石头SELECT id, name FROM user_tab WHERE id = 123，这个SQL中需要强调id不是作为主键，因为id如果是主键，就会直接走主键索引，无法体现覆盖索引中只查询索引中的字段的过程，另外联合索引<id，name>中如果SQL改成SELECT id, name，age FROM user_tab WHERE id = 123就无法实现覆盖索引的效果作者回复: 赞！说得很准确！
2023-07-13归属地：湖南2
sheep你有没有遇到过索引设计不合理引发的线上故障？ 线上ddl操作，需要删除一个索引，然后新建一个，删除之后，出现堆积大量的慢查询；这时候新建索引会被阻塞住（mdl读锁和写锁），后面的查询也一并阻塞住了。 解决办法是：临时关闭服务对外使用，kill掉创建索引后面的查询，待索引创建成功后，服务再恢复使用作者回复: 如果我是面试官，我就会杠，如果不能停掉服务呢？阁下该如何应对？
2023-09-20归属地：广东31
peter确认一下理解：根据文章内容，索引其实是表的一部分数据，如果表的数据是100M，那么，某个索引包含其中的10M数据，这样共有100M + 10M。这10M是表数据之外的数据，是表数据中某部分数据的一个拷贝。比如，表中有一个字段“name = zhangsan”,建立与该name的索引后，磁盘中有两份name。是这样吗？作者回复: 可以这么理解，所以当你在更新数据的时候，MySQL 还需要同步维护索引结构。
2023-07-08归属地：北京1- Geek_c1118e请教一下老师：InnoDB存储引擎的非主键（辅助索引等）和非聚簇索引是否是一个概念，另外，像MyISM中叶子节点存储地址的也是非聚簇索引，所以非聚簇索引是包含这两种格式吗？（：网上看一些相关概念有点混淆，想确认一下
作者回复: 我个人认为只是说法不同，本质是一样的。 不同引擎的数据结构是独立的，它们没什么关系，只是说恰好都是类似的结构而已。
2024-02-11归属地：安徽 
Singin in the Rain关于哈希索引，文中提到『但是 MySQL 的 InnoDB 引擎并不支持这种索引。』这一段表述不是很精确。哈希索引确实用在MEMORY存储引擎中，但是这种索引存在一个变种，自适应哈希索引，InnoDB引擎通过innodb_adaptive_hash_index参数控制在其内部使用。作者回复: 赞赞赞。我这里是指我们作为一个用户，是没办法说创建一个哈希索引的。
2023-08-25归属地：北京
小戴同学请教一下： "这个数据行存放在磁盘里，所以触发磁盘 IO 之后能够读取出来。磁盘 IO 是非常慢的，因此回表性能极差，你在实践中要尽可能避免回表"这句话说回表的性能差的原因，但是前面"一个默认的前提就是索引本身会全部装进内存中，只有真实的数据行会放在磁盘上"，那使用主键索引也需要走磁盘，性能差别就是拿到主键之后再去拿数据的性能差吗？作者回复: 不是的，聚簇索引的非叶子部分是可以直接放在内存的。 话又说回来，如果整个内存不够的话，那么索引还是有可能一直在磁盘上的。
2023-08-11归属地：北京2
江 Nina“如果查询条件是 WHERE A = a1 OR B = b1，那么这个查询并不会使用这个索引。” 这个是为什么呢 明白b不会走索引 但是感觉前一个A会走索引啊作者回复: 严格来说，它走不走索引，不一定。也就是说，如果 MySQL 用 A 索引能加速查询，也就是扫描的行数少，那么它就用；如果用 A 索引，但是 OR 后面的查询条件比起来，B = b1 命中了很多行，那么就不会用 A 的索引，而是直接扫描。 简单来说，就是 OR 两边的条件，MySQL 认为命中的数据越少，就越倾向于用索引。反过来，就不会用索引。
2023-08-04归属地：北京5
