这篇文章主要介绍了MySQL索引提高查询效率的方法，具有一定借鉴价值，需要的朋友可以参考下。希望大家阅读完这篇文章后大有收获。下面让小编带着大家一起了解一下。
正文
MySQL的索引本质上是一种数据结构
让我们先来了解一下计算机的数据加载。
磁盘IO和预读：
先说一下磁盘IO，磁盘读取数据靠的是机械运动，每一次读取数据需要寻道、寻点、拷贝到内存三步操作。
寻道时间是磁臂移动到指定磁道所需要的时间，一般在5ms以下；
寻点是从磁道中找到数据存在的那个点，平均时间是半圈时间，如果是一个7200转/min的磁盘，寻点时间平均是600000/7200/2=4.17ms；
拷贝到内存的时间很快，和前面两个时间比起来可以忽略不计，所以一次IO的时间平均是在9ms左右。听起来很快，但数据库百万级别的数据过一遍就达到了9000s，显然就是灾难级别的了。
考虑到磁盘IO是非常高昂的操作，计算机操作系统做了预读的优化，当一次IO时，不光把当前磁盘地址的数据，而是把相邻的数据也都读取到内存缓冲区内，因为当计算机访问一个地址的数据的时候，与其相邻的数据也会很快被访问到。
每一次IO读取的数据我们称之为一页(page)，具体一页有多大数据跟操作系统有关，一般为4k或8k，也就是我们读取一页内的数据时候，实际上才发生了一次IO。
（突然想到个我刚毕业被问过的问题，在64位的操作系统中，Java中的int类型占几个字节？最大是多少？为什么？）
那我们想要优化数据库查询，就要尽量减少磁盘的IO操作，所以就出现了索引。
索引是什么？
MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。
MySQL 中常用的索引在物理上分两类，B-树索引和哈希索引。
本次主要讲BTree索引。
BTree索引
BTree又叫多路平衡查找树，一颗m叉的BTree特性如下：
- 树中每个节点最多包含m个孩子。
- 除根节点与叶子节点外，每个节点至少有[ceil(m/2)]个孩子（ceil()为向上取整）。
- 若根节点不是叶子节点，则至少有两个孩子。
- 所有的叶子节点都在同一层。
- 每个非叶子节点由n个key与n+1个指针组成，其中[ceil(m/2)-1] <=n <=m-1 。
这是一个3叉（只是举例，真实会有很多叉）的BTree结构图，每一个方框块我们称之为一个磁盘块或者叫做一个block块，这是操作系统一次IO往内存中读的内容，一个块对应四个扇区，紫色代表的是磁盘块中的数据key，黄色代表的是数据data，蓝色代表的是指针p，指向下一个磁盘块的位置。
来模拟下查找key为29的data的过程：
1、根据根结点指针读取文件目录的根磁盘块1。【磁盘IO操作1次】
2、磁盘块1存储17，35和三个指针数据。我们发现17<29<35，因此我们找到指针p2。
3、根据p2指针，我们定位并读取磁盘块3。【磁盘IO操作2次】
4、磁盘块3存储26，30和三个指针数据。我们发现26<29<30，因此我们找到指针p2。
5、根据p2指针，我们定位并读取磁盘块8。【磁盘IO操作3次】
6、磁盘块8中存储28，29。我们找到29，获取29所对应的数据data。
由此可见，BTree索引使每次磁盘I/O取到内存的数据都发挥了作用，从而提高了查询效率。
但是有没有什么可优化的地方呢？
我们从图上可以看到，每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。
B+Tree索引
B+Tree是在B-Tree基础上的一种优化，使其更适合实现外存储索引结构。在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。
B+Tree相对于B-Tree有几点不同：
非叶子节点只存储键值信息， 数据记录都存放在叶子节点中， 将上一节中的B-Tree优化，由于B+Tree的非叶子节点只存储键值信息，所以B+Tree的高度可以被压缩到特别的低。
