mysql数据库索引如何作?

MySQL索引底层的实现，今天简单聊一聊，少讲“是怎么样”，更多说说“为何设计成这样”。

问题1. 数据库为何要设计索引？

图书馆存了1000W本图书，要从中找到《架构师之路》，一本本查，要查到何时去？
因而，图书管理员设计了一套规则：
(1)一楼放历史类，二楼放文学类，三楼放IT类…
(2)IT类，又分软件类，硬件类…
(3)软件类，又按照书名音序排序…
以便快速找到一本书。

与之类比，数据库存储了1000W条数据，要从中找到name=”shenjian”的记录，一条条查，要查到何时去？
因而，要有索引，用于提高数据库的查找速度。

问题2. 哈希(hash)比树(tree)更快，索引结构为何要设计成树型？

加速查找速度的数据结构，常见的有两类：
(1)哈希，例如HashMap，查询/插入/修改/删除的平均时间复杂度都是O(1)；
(2)树，例如平衡二叉搜索树，查询/插入/修改/删除的平均时间复杂度都是O(lg(n))；

能够看到，不论是读请求，仍是写请求，哈希类型的索引，都要比树型的索引更快一些，那为何，索引结构要设计成树型呢？
画外音：80%的同窗，面试都答不出来。

索引设计成树形，和SQL的需求相关。

对于这样一个单行查询的SQL需求：
select * from t where name=”shenjian”;
确实是哈希索引更快，由于每次都只查询一条记录。
画外音：因此，若是业务需求都是单行访问，例如passport，确实可使用哈希索引。

可是对于排序查询的SQL需求：
分组：group by
排序：order by
比较：<、>
…
哈希型的索引，时间复杂度会退化为O(n)，而树型的“有序”特性，依然可以保持O(log(n)) 的高效率。

任何脱离需求的设计都是耍流氓。

多说一句，InnoDB并不支持哈希索引。

问题3. 数据库索引为何使用B+树？
为了保持知识体系的完整性，简单介绍下几种树。

第一种：二叉搜索树

二叉搜索树，如上图，是最为你们所熟知的一种数据结构，就不展开介绍了，它为何不适合用做数据库索引？
(1)当数据量大的时候，树的高度会比较高，数据量大的时候，查询会比较慢；
(2)每一个节点只存储一个记录，可能致使一次查询有不少次磁盘IO；
画外音：这个树常常出如今大学课本里，因此最为你们所熟知。

第二种：B树

B树，如上图，它的特色是：
(1)再也不是二叉搜索，而是m叉搜索；
(2)叶子节点，非叶子节点，都存储数据；
(3)中序遍历，能够得到全部节点；
画外音，实在不想介绍这个特性：非根节点包含的关键字个数j知足，(┌m/2┐)-1 <= j <= m-1，节点分裂时要知足这个条件。

B树被做为实现索引的数据结构被创造出来，是由于它可以完美的利用“局部性原理”。

什么是局部性原理？
局部性原理的逻辑是这样的：
(1)内存读写块，磁盘读写慢，并且慢不少；

(2)磁盘预读：磁盘读写并非按需读取，而是按页预读，一次会读一页的数据，每次加载更多的数据，若是将来要读取的数据就在这一页中，能够避免将来的磁盘IO，提升效率；
画外音：一般，一页数据是4K。

(3)局部性原理：软件设计要尽可能遵循“数据读取集中”与“使用到一个数据，大几率会使用其附近的数据”，这样磁盘预读能充分提升磁盘IO；

B树为什么适合作索引？
(1)因为是m分叉的，高度可以大大下降；
(2)每一个节点能够存储j个记录，若是将节点大小设置为页大小，例如4K，可以充分的利用预读的特性，极大减小磁盘IO；

第三种：B+树

B+树，如上图，还是m叉搜索树，在B树的基础上，作了一些改进：
(1)非叶子节点再也不存储数据，数据只存储在同一层的叶子节点上；
画外音：B+树中根到每个节点的路径长度同样，而B树不是这样。

(2)叶子之间，增长了链表，获取全部节点，再也不须要中序遍历；

这些改进让B+树比B树有更优的特性：
(1)范围查找，定位min与max以后，中间叶子节点，就是结果集，不用中序回溯；
画外音：范围查询在SQL中用得不少，这是B+树比B树最大的优点。

(2)叶子节点存储实际记录行，记录行相对比较紧密的存储，适合大数据量磁盘存储；非叶子节点存储记录的PK，用于查询加速，适合内存存储；

(3)非叶子节点，不存储实际记录，而只存储记录的KEY的话，那么在相同内存的状况下，B+树可以存储更多索引；

最后，量化说下，为何m叉的B+树比二叉搜索树的高度大大大大下降？
大概计算一下：
(1)局部性原理，将一个节点的大小设为一页，一页4K，假设一个KEY有8字节，一个节点能够存储500个KEY，即j=500
(2)m叉树，大概m/2<= j <=m，便可以差很少是1000叉树
(3)那么：
一层树：1个节点，1500个KEY，大小4K
二层树：1000个节点，1000500=50W个KEY，大小10004K=4M
三层树：10001000个节点，10001000500=5亿个KEY，大小100010004K=4G
画外音：额，帮忙看下有没有算错。

能够看到，存储大量的数据（5亿），并不须要过高树的深度（高度3），索引也不是太占内存（4G）。

总结数据库索引用于加速查询虽然哈希索引是O(1)，树索引是O(log(n))，但SQL有不少“有序”需求，故数据库使用树型索引InnoDB不支持哈希索引数据预读的思路是：磁盘读写并非按需读取，而是按页预读，一次会读一页的数据，每次加载更多的数据，以便将来减小磁盘IO局部性原理：软件设计要尽可能遵循“数据读取集中”与“使用到一个数据，大几率会使用其附近的数据”，这样磁盘预读能充分提升磁盘IO数据库的索引最经常使用B+树：(1)很适合磁盘存储，可以充分利用局部性原理，磁盘预读；(2)很低的树高度，可以存储大量数据；(3)索引自己占用的内存很小；(4)可以很好的支持单点查询，范围查询，有序性查询；