『傻大方摘要_[MySQL]阿里面试官，直接重置了我对索引的了解（二）』一样先看一下B加的结构： 我们可以发现同样的元素 ， B+树的表示要比B树要“胖” ， 原因在于B+树中的非叶子节点会冗余一份在叶子节点中 ， 并且叶子节点之间用指针相连 。 那么B+树到底有什么优势呢？ 其实很简单...
按关键词阅读：
一样先看一下B加的结构：
我们可以发现同样的元素 ， B+树的表示要比B树要“胖” ， 原因在于B+树中的非叶子节点会冗余一份在叶子节点中 ， 并且叶子节点之间用指针相连 。
那么B+树到底有什么优势呢？其实很简单 ， 我们看一下上面的数据结构 ， 最开始的Hash不支持范围查询 ， 二叉树树高很高 ， 只有B树跟B+有的一比 。
B树一个节点可以存储多个元素 ， 相对于完全平衡二叉树整体的树高降低了 ， 磁盘IO效率提高了 。
而B+树是B树的升级版 ， 只是把非叶子节点冗余一下 ， 这么做的好处是为了提高范围查找的效率 。
提高了的原因也无非是会有指针指向下一个节点的叶子节点 。
小结：到这里可以总结出来 ， Mysql选用B+树这种数据结构作为索引 ， 可以提高查询索引时的磁盘IO效率 ， 并且可以提高范围查询的效率 ， 并且B+树里的元素也是有序的 。
那么 ， 一个B+树的节点中到底存多少个元素最合适你有了解过么？额这个这个？卧*有点懵逼呀 。
过了一会还是没想出 ， 只能老实交代：这个不是很了解咳咳 。
你可以换个角度来思考B+树中一个节点到底多大合适？B+树中一个节点为一页或页的倍数最为合适 。
为啥？因为如果一个节点的大小小于1页 ， 那么读取这个节点的时候其实也会读出1页 ， 造成资源的浪费 。
如果一个节点的大小大于1页 ， 比如1.2页 ， 那么读取这个节点的时候会读出2页 ， 也会造成资源的浪费 。
所以为了不造成浪费 ， 所以最后把一个节点的大小控制在1页、2页、3页、4页等倍数页大小最为合适 。
你提到了页的概念 ， 能跟我简单说一下么？首先Mysql的基本存储结构是页(记录都存在页里边)：
- 各个数据页可以组成一个双向链表
- 而每个数据页中的记录又可以组成一个单向链表
- - 每个数据页都会为存储在它里边儿的记录生成一个页目录 ， 在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽 ， 然后再遍历该槽对应分组中的记录即可快速找到指定的记录
- 以其他列(非主键)作为搜索条件：只能从最小记录开始依次遍历单链表中的每条记录 。
- 定位到记录所在的页
- - 需要遍历双向链表 ， 找到所在的页
- 从所在的页内中查找相应的记录
- - 由于不是根据主键查询 ， 只能遍历所在页的单链表了
哦？回表你聊一下 。卧槽 ， 该死 ， 我嘴干嘛 。
回表大概就是我们有个主键为ID的索引 ， 和一个普通name字段的索引 ， 我们在普通字段上搜索：
select * from table where name = '丙丙'
执行的流程是先查询到name索引上的“丙丙” ， 然后找到他的id是2 ， 最后去主键索引 ， 找到id为2对应的值 。
回到主键索引树搜索的过程 ， 就是回表 。 不过也有方法避免回表 ， 那就是覆盖索引 。
哦？那你再跟我聊一下覆盖索引呗？！！！ 我这个嘴 。。。
这个其实比较好理解 ， 刚才我们是 select *， 查询所有的 ， 我们如果只查询ID那 ， 其实在Name字段的索引上就已经有了 ， 那就不需要回表了 。
覆盖索引可以减少树的搜索次数 ， 提升性能 ， 他也是我们在实际开发过程中经常用来优化查询效率的手段 。
很多联合索引的建立 ， 就是为了支持覆盖索引 ， 特定的业务能极大的提升效率 。
索引的最左匹配原则知道么？最左匹配原则：
- 索引可以简单如一个列 (a) ， 也可以复杂如多个列 (abcd) ， 即联合索引 。
- 如果是联合索引 ， 那么key也由多个列组成 ， 同时 ， 索引只能用于查找key是否存在（相等） ， 遇到范围查询 (>、<、between、like左匹配)等就不能进一步匹配了 ， 后续退化为线性查找 。
- 因此 ， 列的排列顺序决定了可命中索引的列数 。
- 如有索引 (abcd) ， 查询条件 a=1 and b=2 and c>3 and d=4 ， 则会在每个节点依次命中a、b、c ， 无法命中d 。 (c已经是范围查询了 ， d肯定是排不了序了)
上面谈的其实就是索引最基本的东西 ， N叉树 ， 跳表、LSM我都没讲 ， 同时要创建出好的索引要顾及到很多的方面：
来源：(程序猿的秃头)
【傻大方】网址：http://www.shadafang.com/c/gs03112946122020.html
标题：[MySQL]阿里面试官，直接重置了我对索引的了解（二）
