时间复杂度(数据库索引B-Tree树实战)
时间复杂度是一个函数，它定量描述了该算法的运行时间。常见的时间复杂度有以下几种。
O(1)，log(2)n，n，n log(2)n ，n的平方，n的三次方，2的n次方，n!。
O(1)指的是常数。即无论算法的输入n是多大，都不会影响到算法的运行时间,这种是最优的算法。
而O(n!)阶乘是非常差的算法。当n变大时，算法所需的时间是不可接受的。
用通俗的话来描述，我们假设n=1所需的时间为1秒。那么当n = 10000时。
O(1)的算法需要1秒执行完毕。
O(n)的算法需要10，000秒 ≈ 2.7小时 执行完毕。
O(n2)的算法需要100，000，000秒 ≈ 3.17年 执行完毕。
O(n!)的算法需要(zh.numberempire.com/factorialca…
可见算法的时间复杂度影响有多大。
所以O(1)和O(n)差了2.7小时，区别显而易见。
假如一张表有一亿条数据 ，需要查找其中某一条数据，按照常规逻辑， 一条一条的去匹配的话， 最坏的情况下需要匹配一亿次才能得到结果，用大O标记法就是O(n)最坏时间复杂度，这是无法接受的，而且这一亿条数据显然不能一次性读入内存供程序使用。
因此， 这一亿次匹配在不经缓存优化的情况下就是一亿次IO开销，以现在磁盘的IO能力和CPU的运算能力， 有可能需要几个月才能得出结果 。
如果把这张表转换成平衡树结构(一棵非常茂盛和节点非常多的树)。
假设这棵树有10层，那么只需要10次IO开销就能查找到所需要的数据， 速度以指数级别提升。
用大O标记法就是O(log n)，n是记录总数，底数是树的分叉数，结果就是树的层次数。
换言之，查找次数是以树的分叉数为底，记录总数的对数，用公式来表示就是
用程序来表示就是Math.Log(100000000,10)，100000000是记录数，10是树的分叉数(真实环境下分叉数远不止10), 结果就是查找次数=8，这里的结果从亿降到了个位数。
因此，利用索引会使数据库查询有惊人的性能提升。
什么是索引
在MySQL中，主要有四种类型的索引，分别为：B-Tree索引，Hash索引，Fulltext索引和R-Tree索引，本文讲的是B-Tree索引。
索引（Index）是帮助数据库高效获取数据的数据结构,提取主干:索引是数据结构。 索引是在基于数据库表创建的，它包含一个表中某些列的值以及记录对应的地址，并且把这些值存储在一个数据结构中。
索引是数据结构,最常见的就是使用哈希表、B+树作为索引。
为什么要使用索引
数据库查询是数据库最主要的功能之一。而查询速度当然是越快越好。而当数据量越来越大的时候，查询花费的时间会随之增长。
而索引，可以加速数据的查询。因为索引是有序排列的。
举个例子来说，假设我们有一个数据库表Employee，这个表分别有三个字段：name，age，address。假设表中有1000条记录。
假如没有使用索引，当我们查询名为“Jesus”的雇员的时候，即调用：
select name,age,address from Employee where name = 'Jesus';
此时数据库不得不在Employee表中对这1000条记录一条一条的进行判断name字段是否为“Jesus”。这也就是所谓的全表扫描。
而当我们在Employee表上的name字段上创建索引时，当我们查询名为“Jesus”的雇员时，会通过索引查找去查询名为“Jesus”的雇员。
因为该索引已经按照字母顺序排列，因此要查找名为“Jesus”的记录时会快很多，因为名字首字母为“J”的雇员都是排列在一起的。通过该索引，能获取到表中对应的记录。
使用索引的好处:加快查询速度
假设索引是链表结构。每个节点存储的是关键字字段（这个例子中对应的是name属性）以及该关键字字段在数据库表的对应的记录的地址。而这些节点是根据name属性排序的（即根据字母顺序排序）。
因此，当我们执行上面说的查找名为“Jesus”的sql语句时，数据库会通过该索引来查询，因为该链表是有序排列的，在我们找到第一个name属性为“Jesus”的节点后，继续往后找，当遇到name属性不为“Jesus”的节点时，就无需再往后查找了，因为节点是根据name属性有序排列的啊。
假设第一个name=“Jesus”的节点是第499个节点，最后一个name=“Jesus”的节点是第500个节点，那么只需要遍历501个节点就可以了。
当发现第501个节点的name字段不为“Jesus”，后面的499个节点也就无需遍历了。
通过索引，我们就找到了name为“Jesus”的节点，而通过该节点的另一个属性（关键字字段在数据库表的对应的记录的地址），我们就能获取到Employee表中满足条件name=“Jesus”的记录了。
通过使用索引，查询判断的次数就从1000次缩小到了501次了。起到了加速了查询效率。但实际上数据库中索引的结构，并不是链表结构。
数据库中使用什么数据结构作为索引
Hash索引
mysql中，只有Memory(Memory表只存在内存中，断电会消失，适用于临时表)存储引擎显示支持Hash索引，是Memory表的默认索引类型，尽管Memory表也可以使用B+Tree索引。
Hash索引把数据以hash形式组织起来，因此当查找某一条记录的时候，速度非常快。但是因为hash结构，每个键只对应一个值，而且是散列的方式分布。
所以它并不支持范围查找和排序等功能,简直致命。
链表
数据库中实际使用的索引并不会是链表结构，因为效率太低了。我们知道链表的查询效率是O(n)。
就像上面的例子，遍历了501次才找到第一条符合条件的记录，这是很低效的。
数组
数组 + 二分查找的效率是O(logn)，但数组的插入元素以及删除元素的效率很低，因此使用数组做为索引结构并不合适。
另外，在选择数据库索引的结构的时候，要考虑到另一个问题。索引是存在于磁盘中，当索引非常大的时候，达到几个G的时候，无法一次加载到内存中。
考虑到上面两个因素，数据库中索引使用的是树形结构,树形结构是计算机系统里最重要的数据结构。 各种树的名字,有这么几种树：
B-TreeB+TreeB Tree
首先要明白三种树名中的“-”起到的是分隔的作用，并不是“减”的意思。
因此正确的翻译应该是B树而不是B-树。
因此，当你听到别人说“B减树”的时候，要明白它指的是B-Tree。即B树和B-树是同一种树。
为什么要强调上面这一点呢，因为有的博文中写的是：B树是二叉树，B-树是多路搜索树。
然而B树和B-树都是指B-Tree。引用维基百科上的话：
B-tree
Not to be confused with Binary tree.
B-Tree并不是Binart tree即二叉树。B-Tree的中文名是平衡多路搜索树。
普通二叉树
极端情况退化链表
我们知道，二叉树的查找的时间复杂度是O(log2N)，其查找效率与深度有关，而普通的二叉树可能由于内部节点排列问题退化成链表，这样查找效率就会很低。
因此平衡二叉树是更好的选择，因为它保持平衡，即通过旋转调整结构保持最小的深度。其查找的时间复杂度也是O(log2N)。
但实际上，数据库中索引的结构也并非AVL树或更优秀的红黑树，尽管它的查询的时间复杂度很低。
平衡二叉树(红黑树)
平衡二叉树是一种二叉排序树，左子树和右子树深度的绝对值不超过1。
之前说了平衡树的查找时间复杂度是O(log2N),b避免了普通二叉树退换为链表的问题已经很不错了，但还是不适合作为索引结构。
那么肯定是有一种更适合作为索引的数据结构。
那么这个更适合作为索引的数据结构，难道是查找的时间复杂度更低吗？
并不是。这种作为索引的数据结构的查找的时间复杂度也近似O(log2N)。
那为什么平衡二叉树不适合作为索引呢？
索引是存在于索引文件中，是存在于磁盘中的。因为索引通常是很大的，因此无法一次将全部索引加载到内存当中，因此每次只能从磁盘中读取一个磁盘页的数据到内存中。而这个磁盘的读取的速度较内存中的读取速度而言是差了好几个级别。
无法利用磁盘预读
逻辑相近节点物理结构很远:无法利用磁盘预读
注意，我们说的平衡二叉树结构，指的是逻辑结构上的平衡二叉树，其物理实现是数组。然后由于在逻辑结构上相近的节点在物理结构上可能会差很远。因此，每次读取的磁盘页的数据中有许多是用不上的。因此，查找过程中要进行许多次的磁盘读取操作。
个人对逻辑结构上的平衡二叉树，其物理实现是数组。然后由于在逻辑结构上相近的节点在物理结构上可能会差很远的理解是8和4虽然在逻辑结构上很近,但是在存储时可能在不同的磁盘页上面,因此虽然读取了8所在的磁盘页,但是对于4还有再做一次磁盘io读取才行。
而适合作为索引的结构应该是尽可能少的执行磁盘IO操作，因为执行磁盘IO操作非常的耗时。因此，平衡二叉树并不适合作为索引结构
B树(B-树)
平衡二叉树没能充分利用磁盘预读功能。B树是为了充分利用磁盘预读功能来而创建的一种数据结构，也就是说B树就是为了作为索引才被发明出来的的。
局部性原理与磁盘预读
来看看关于“局部性原理与磁盘预读”的知识：
由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。
为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。
这样做的理论依据是计算机科学中著名的空间局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。 程序运行期间所需要的数据通常比较集中。由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高I/O效率。
搞清楚上面的意思。磁盘预读是具体实现，其理论依据是局部性原理。
为什么说红黑树没能充分利用磁盘预读功能，引用一篇博文的一段话：
红黑树这种结构，h明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O(h)，效率明显比B-Tree差很多。
也就是说，使用红黑树（平衡二叉树）结构的话，每次磁盘预读中的很多数据是用不上的数据。因此，它没能利用好磁盘预读的提供的数据。然后又由于深度大（较B树而言），所以进行的磁盘IO操作更多。
B树的每个节点可以存储多个关键字，它将节点大小设置为磁盘页的大小，充分利用了磁盘预读的功能。每次读取磁盘页时就会读取一整个节点。也正因每个节点存储着非常多个关键字，树的深度就会非常的小。进而要执行的磁盘读取操作次数就会非常少，更多的是在内存中对读取进来的数据进行查找。
B树的查询，主要发生在内存中，而平衡二叉树的查询，则是发生在磁盘读取中。因此，虽然B树查询的次数不比平衡二叉树的次数少，但是相比起磁盘IO速度，内存中比较的耗时就可以忽略不计了。因此，B树更适合作为索引。
B+树
比B树更适合作为索引的结构是B+树。MySQL中也是使用B+树作为索引。它是B树的变种，因此是基于B树来改进的。为什么B+树会比B树更加优秀呢？
B树：有序数组+平衡多叉树； B+树：有序数组链表+平衡多叉树；
非叶子节点只存储索引,分支更多
在上面的时间复杂度里我们提到过:n是记录总数，底数是树的分叉数，结果就是树的层次数。
也就是说底数越大,数的层数越低,也就是磁盘io的次数越少。
b+树的非叶子节点不保存数据，只保存子树的临界值（最大或者最小），所以同样大小的节点，b+树相对于b树能够有更多的分支，使得这棵树更加矮胖，查询时做的IO操作次数也更少。
B+树的关键字全部存放在叶子节点中，非叶子节点用来做索引，而叶子节点中有一个指针指向一下个叶子节点。做这个优化的目的是为了提高区间访问的性能。而正是这个特性决定了B+树更适合用来存储外部数据。
最主要的是这棵树矮胖，呵呵。一般来说，索引很大，往往以索引文件的形式存储的磁盘上，索引查找时产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的时间复杂度。树高度越小，I/O次数越少。
那为什么是B+树而不是B树呢，因为它内节点不存储data，这样一个节点就可以存储更多的key。
B+树扫库更方便
B+树还有一个最大的好处，方便扫库，B树必须用中序遍历的方法按序扫库，而B+树直接从叶子结点挨个扫一遍就完了，B+树支持range-query非常方便，而B树不支持。这是数据库选用B+树的最主要原因。
比如要查 5-10之间的，B+树一把到5这个标记，再一把到10，然后串起来就行了，B树就非常麻烦。
数据库索引采用B+树的主要原因是B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。正是为了解决这个问题，B+树应运而生。B+树只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作（或者说效率太低）。
正如上面所说，在数据库中基于范围的查询是非常频繁的，因此MySQL最终选择的索引结构是B+树而不是B树。
为什么Redis不用B+树
因为B+树的原理是 叶子节点存储数据，非叶子节点存储索引，B+树的每个节点可以存储多个关键字，它将节点大小设置为磁盘页的大小，充分利用了磁盘预读的功能。
每次读取磁盘页时就会读取一整个节点,每个叶子节点还有指向前后节点的指针，为的是最大限度的降低磁盘的IO;因为数据在内存中读取耗费的时间是从磁盘的IO读取的百万分之一
Redis是 内存中读取数据，不涉及IO
Redis是 内存中读取数据，不涉及IO，因此使用了跳表。
redis使用跳表不用B+数的原因是：redis是内存数据库，而B+树纯粹是为了mysql这种IO数据库准备的。B+树的每个节点的数量都是一个mysql分区页的大小16K。
