为什么选择B+树作为Innodb索引数据结构

数据物理存储方式可分为顺序存储和链式存储，数据逻辑存储方式可以分为线性和非线程。为什么要从众多组合中选择链接结构的B+树作为innodb索引，一个好的索引不仅查询效率高，同时在数据更新的过程中需要对索引进行维护，还需要保证索引维护成本不能太高，B+Tree很好的满足了这两点。

数组

有序数组使用二分查找时间复杂度未lgN，对查找到的元素，直接进行更新时和删除（设置为null避免后面移动），对查找、更新和删除来说，数组作为索引性能还不错，但向数组中某一个位置插入元素，确无法找到有效办法避免后面元素的位置移动。

hash表

hash表CURD时间复杂度都为O(1),乍一看非常适合做数据库索引，但hash表对数据库中范围查询场景非常不友好，在hash表中查询一个范围内的所有数据，需要对范围查询中的每条记录进行一次hash。

二叉搜索树

当插入元素正好有序，二叉搜索树将退化为单链表，查询时间复杂度变成o(n)，在软件设计中，我们需要消除极端情况。

平衡二叉树和红黑树

相比于二叉搜索树，平衡二叉树和红黑树避免二叉搜索树退化为单链表。平衡二叉树和红黑树在插入和删除时需要对树进行调整，会有性能消耗，但进行CURD操作时间复杂度依然为lgN，并且对平衡二叉树和红黑树进行中序遍历可以得到有序序列。在不考虑算法实现复杂度的前提下，目前来看使用这两种结构作为索引似乎没有什么问题，在HashMap中也是使用红黑树解决冲突，但有一点需要注意，HashMap中的红黑树在查询时是全部存储在内存中，对于上亿级别的数据库，数据库中每个表中都需要创建大量的索引，无法将全部索引一下子全部都加载到内存中，此时I/O读写效率和次数称为影响查询效率的主要因素。

假设红黑树每个非叶子节点只存储了key和指向左右孩子的指针，叶子节点存储了完整数据，一个key占8个字节，一个指针占6个字节，一条记录占1kb，则数据量为1亿的表维护一个索引非叶子需要占用的内存空间大小为100，000，000 *（8byte+6byte）➗1024➗1024=1.3M，空间占用很小，没问题，似乎也没有什么问题。叶子节点占用的空间大小为100，000，000 * 1KB➗1024➗1024 = 95G。95G数据显然无法将一下加载进入内存，需要分页将数据加载进内存。在查询过程中，第一、希望每次加载进内存的数据是有用，第二、二叉树和红黑树都是链式结构 ，只有判断了父节点的值，才能确定下一步要查找的是左子树和右子树，基于这两点考虑，一种有效加载索引数据的方式是以节点为单位从磁盘加载索引，查询过程中使用的每一个节点都需要进行一次I/O操作，树的高度决定了使用索引时的I/O次数，1亿条数据的索引，二叉树的高度为lg（100，000，000）=26.57，需要进行27次IO，效率将非常慢。

B-Tree/B+Tree

平衡二叉树在进行CURD效率都已经很好了，唯一缺点就是I/O读取次数太多，I/O读取次数等于树的高度，分析，树高h = loga(N),在N一定情况下，a的和树高成反比，a = 2时是二叉树，a>2是多叉树，B-Tree/B+Tree,刚好满足这样的要求。

通过对比上面两个B-Tree和B+Tree数据结构图，二者主要区别有两点：

区别1： 相同高度的B+树存储的记录数更多。
Innodb数组最小组织单位是page，每个节点为一页，这样一次可以读取到一个节点的所有数据，每页大小为16kb，假设每个key占4个字节，每个指针占4个字节，每条记录占1kb，每个节点可以存储数据为16KB1024➗（6+4+1024）=15.84，则高度3的B-Tree可以存储的节点为16^3=4096;B+Tree,叶子节点可以存储16个，非叶子节点只用来存储key和指针，单个节点可以存储的key为16KB1024➗（8+6）= 1638，高度为3的B+Tree可以存储的节点为1638^2*16=42,928,704,千万级别。

区别2： B+Tree范围查找和排序效率更高。
B+Tree 树中叶子节点使用双向链表存储，从做到右按照升序排列，双向链表实现了升序和降序两种方式读取数据。
order by 工作原理，todo…