索引是一种用于快速查询行的数据结构，就像一本书的目录就是一个索引，如果想在一本书中找到某个主题，一般会先找到对应页码。在mysql中，存储引擎用类似的方法使用索引，先在索引中找到对应值，然后根据匹配的索引记录找到对应的行。

我们首先了解一下索引的几种类型和索引的结构。

索引类型

B树

大多数存储引擎都支持B树索引。b树通常意味着所有的值都是按顺序存储的，并且每一个叶子也到根的距离相同。B树索引能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取数据。下图就是一颗简单的B数。

B树的查询流程：

如上图我要从找到E字母，查找流程如下：

获取根节点的关键字进行比较，当前根节点关键字为M，E<M（26个字母顺序），所以往找到指向左边的子节点（二分法规则，左小右大，左边放小于当前节点值的子节点、右边放大于当前节点值的子节点）；
拿到关键字D和G，D<E<G 所以直接找到D和G中间的节点；
拿到E和F，因为E=E 所以直接返回关键字和指针信息（如果树结构里面没有包含所要查找的节点则返回null）；
通过指针信息取出这条记录的所有信息；

B+树

下图为B+树的结构，B+树是B树的升级版，我们可以观察一下，B树和B+树的区别是什么？

B+树和B树的区别是：

B树的节点中没有重复元素，B+树有。
B树的中间节点会存储数据指针信息，而B+树只有叶子节点才存储。
B+树的每个叶子节点有一个指针指向下一个节点，把所有的叶子节点串在了一起。

从下图我们可以直观的看到B树和B+树的区别：紫红色的箭头是指向被索引的数据的指针，大红色的箭头即指向下一个叶子节点的指针。

我们假设被索引的列是主键，现在查找主键为5的记录，模拟一下查找的过程：

B树，在倒数第二层的节点中找到5后，可以立刻拿到指针获取行数据，查找停止。

B+树，在倒数第二层的节点中找到5后，由于中间节点不存有指针信息，则继续往下查找，在叶子节点中找到5，拿到指针获取行数据，查找停止。

B+树每个父节点的元素都会出现在子节点中，是子节点的最大（或最小）元素。叶子节点存储了被索引列的所有的数据。

那B+树比起B树有什么优点呢？

由于中间节点不存指针，同样大小的磁盘页可以容纳更多的节点元素，树的高度就小。（数据量相同的情况下，B+树比B树更加“矮胖”），查找起来就更快。
B+树每次查找都必须到叶子节点才能获取数据，而B树不一定，B树可以在非叶子节点上获取数据。因此B+树查找的时间更稳定。
B+树的每一个叶子节点都有指向下一个叶子节点的指针，方便范围查询和全表查询：只需要从第一个叶子节点开始顺着指针一直扫描下去即可，而B树则要对树做中序遍历。

了解了B+树的结构之后，我们对一张具体的表做分析：

create table Student(last_name varchar(50) not null, first_name varchar(50) not null, birthday date not null, gender int(2) not null, key(last_name, first_name, birthday)
);

对于表中的每一行数据，索引中包含了name，birthday列的值。下图显示了该索引的结构：

索引对多个值进行排序的依据是create table语句中定义索引时列的顺序，即如果名字相同，则根据生日来排序。

B+树的结构决定了这种索引对以下类型的查询有效：

全值匹配 和索引中所有的列进行匹配，例如查找姓名为Cuba Allen，生日为1960-01-01的人。
匹配最左前缀 查找姓为Allen的人，即只用索引的第一列。
匹配列前缀 匹配某一列的值的开头部分，例如查找所有以J开头的姓的人。
匹配范围值 查找姓在Allen和Barrymore之间的人。
精确匹配某一列并范围匹配另外一列 查找姓为Allen，名字是字母K开头的人。即第一列last_name全匹配，第二列first_name范围匹配。
只访问索引的查询 查询只需要访问索引，无需访问数据行。这种索引叫做覆盖索引。

一些限制：

如果不是按照索引的最左列开始查找，无法使用索引。例如上面例子中的索引无法用于查找某个特定生日的人，因为生日不是最左数据列。也不能查找last_name以某个字母结尾的人。
不能跳过索引的列。上述索引无法用于查找last_name为Smith并且某个特定生日的人。如果不指定first_name，则mysql只能使用索引的第一列。
如果查询中有某个列的范围查询，则右边所有的列都无法使用索引优化查找。例如查询WHERE last_name=’Smith’ AND first_name LIKE ‘J%’ AND birthday=‘1996-05-19’，这个查询只能使用索引的前两列。

哈希索引

哈希索引，只有精确匹配索引所有列的查询才有效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。如果多个列的哈希值相同，索引会以链表的方式存放多个指针记录到同一个哈希条目中。

因为索引自身只存储对应的哈希值，所以索引的结构十分紧凑，哈希索引查找的速度非常快。但是哈希索引也有它的限制：

哈希索引不是按照索引顺序存储的，无法用于排序。
不支持部分索引列匹配查找。
不支持范围查找。

聚集索引（clusterd index）

每个存储引擎为InnoDB的表都有一个特殊的索引，叫聚集索引。聚集索引并不是一种单独的索引类型，而是一种数据存储方式。当表有聚集索引的时候，它的数据行实际上存放在叶子页中。一个表不可能有两个地方存放数据，所以一个表只能有一个聚集索引。

因为是存储引擎负责实现索引，因此不是所有的存储引擎都支持聚集索引。InnoDB表中聚集索引的索引列就是主键，所以聚集索引也叫主键索引。

例如下面这张InnoDB表：

create table Student(id int(11) primary key auto_increment,last_name varchar(50) not null, first_name varchar(50) not null, birthday date not null
);

聚集索引（主键索引）的结构如下图：

这是一课B+树，它的叶子页包含了行的全部数据，节点页只包含了索引列（即主键）。

二级索引（secondary indexes）

对于InnoDB表，在非主键列的其他列上建的索引就是二级索引（因为聚集索引只有一个）。二级索引可以有0个，1个或者多个。二级索引和聚集索引的区别是什么呢？二级索引的节点页和聚集索引一样，只存被索引列的值，而二级索引的叶子页除了索引列值，还存这一列对应的主键值。

InnoDB和MyISAM的数据分布对比

以下表为例，我们看下InnoDB和MyISAM是如何存储这个表的：

create table layout_test(col1 int(11) primary key, col2 int(11) not null, key(col2)
);

InnoDB表的数据分布

聚集索引（主键索引）分布如下：

可以看到，叶子节点存储了整个表的数据，而不是只有索引列，每个叶子节点包含了主键值、事务ID、用于事务和MVCC的回滚指针以及所有的剩余列（col2）。

二级索引分布如下：

二级索引的叶子节点中存储的不是“行指针”，而是主键值，并以此作为指向行的“指针”。这样的策略减少了当出现行移动或者数据页分裂时二级索引的维护工作。使用主键当做指针会让二级索引占更多空间，但好处是InnoDB在移动行时无需更新二级索引中的这个指针。

MyISAM表的数据分布

col1列上的索引：

col2列上的索引：

实际上MyISAM中主键索引和其他索引在结构上没有什么不同。

从下图可以看出InnoDB和MyISAM保存数据和索引的区别。

聚集索引的优点：

可以把相关数据保存在一起，例如实现电子邮箱时，根据用户ID来聚集数据，读取少数的数据页就能获取某个用户的全部邮件。
聚集索引将索引和数据保存在同一个B树中，因此从聚集索引中获取数据比在非聚集索引中要快一些。

聚集索引的缺点：

插入速度严重依赖插入顺序。按照主键的顺序插入是加载数据到InnoDB表中速度最快的方式。假如磁盘中的某一个已经存满了，但是新增的行要插入到这一页当中，存储引擎就会把该也分裂成两个页面来容纳该行，这就是一次页分裂操作。页分裂会导致表占用更多的磁盘空间。
更新聚集索引列的代价很高，会强制InnoDB将每个被更新的行移动到新的位置。
用二级索引访问数据需要两个索引查找，不是一次。因为要先从二级索引的叶子节点获得主键值，再根据这主键去聚集索引中查到对应的行，所以需要两次B树查找。

顺序主键的策略：

在InnoDB表中使用自增主键是既简单性能又高的策略，这样可以保证数据按顺序写入。最好避免随机的聚集索引，从性能的角度考虑，使用UUID来作为聚集索引是很糟糕的，这样不仅插入行花费的时间长，而且索引占用的空间也更大。

转自：https://www.cnblogs.com/yuanrw/p/10225659.html

MySQL索引的原理，B+树、聚集索引和二级索引的结构分析相关推荐

mysql聚集索引 myisam_一句话说清聚集索引和非聚集索引以及MySQL的InnoDB和MyISAM
版权声明:本文为博主原创文章,未经博主允许不得转载.https://blog.csdn.net/21aspnet/article/details/89303988 聚集索引和非聚集索引以及MySQL的 ...
mysql InnoDB 聚集索引，二级索引
InnoDB 索引分为聚集索引(聚簇索引)与二级索引. 聚集索引: 1: 全表唯一且必有一个,主键索引属于聚集索引. 2: 索引项的顺序就是表中数据记录的物理顺序. 3: 若定义了主键索引InnoDB ...
MySQL中B+树索引，聚簇索引，二级索引，辅助索引，回表，索引生效条件
对于MySQL,我们经常说调优有一个手段就是加索引,那么为什么加索引能够优化查询,是不是加了索引查询就快了 ? 在MySQL中,存储的单元并不是按照我们理解的一条一条记录,而是按照页来进行存储的,My ...
【Mysql】InnoDB 中 B+ 树索引的注意事项
一.根页面万年不动在之前的文章里,为了方便理解,都是先画存储用户记录的叶子节点,然后再画出存储目录项记录的内节点. 但实际上 B+ 树的行成过程是这样的: 每当为某个表创建一个 B+ 树索引,都会为 ...
mysql innodb 二级索引,mysql InnoDB index 主键采用聚簇索引，二级索引不采用聚簇索引...
我的归纳: (1)InnoDB的主键采用聚簇索引存储,使用的是B+Tree作为索引结构,但是叶子节点存储的是索引值和数据本身(注意和MyISAM的不同). (2)InnoDB的二级索引不使用聚蔟索引, ...
mysql 排序后下一条记录_什么是MySQL InnoDB 二级索引的排序？｜附实例详解
概述今天主要给大家介绍了关于MySQL InnoDB 二级索引的排序的相关资料,通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值. 每个InnoDB表具有一个特殊的索引称为聚簇 ...
mysql索引之二级索引学习总结
二级索引又称辅助索引.非聚集索引(no-clustered index).b+tree树结构.然而二级索引的叶子节点不保存记录中的所有列,其叶子节点保存的是<健值,(记录)地址>.好似聚集 ...
bcp 不能调用where 子句_技术分享 || Mysql中IS NULL、IS NOT NULL不能走索引？
mysql中IS NULL.IS NOT NULL不能走索引? 不知道是啥原因也不知道啥时候, 江湖上流传着这么一个说法 mysql查询条件包含IS NULL.IS NOT NULL.!=.like ...
MySQL聚簇索引和二级索引的区别
主键索引的叶子节点存的是整行数据.在InnoDB里,主键索引也被称为聚簇索引(clustered index). 非主键索引的叶子节点内容是主键的值.在InnoDB里,非主键索引也被称为二级索引(se ...
MySql中当in或or参数过多时导致索引失效
今天的文章很短只讲一件事情,但发现很多同学还不知道,以至于引发一些数据库使用层面的慢查询.访问超时问题. mysql有个阈值,决定了阈值之下使用索引查询,而超过阈值则退化,优化器选择索引下潜,进而引起 ...

MySQL索引的原理，B+树、聚集索引和二级索引的结构分析