一、索引及其优缺点

1.1、索引概述

??索引（Index）是帮助MySQL高效获取数据的数据结构，索引的本质是数据结构。索引是在存储引擎中实现的，因此每种存储引擎的索引不一定相同，并且每种存储引擎不一定支持所有索引类型。同时，存储引擎可以定义每一个表的最大索引数和最大索引长度。所有存储引擎支持每个表至少16个索引，总索引长度至少为256个字节。有些存储引擎支持更多的索引数和更大的索引长度。

1.2、优点

• 提高数据检索的效率，降低数据库的IO成本，这也是创建索引最主要的原因
• 通过创建唯一索引，可以保证数据库表中每一行数据的唯一性
• 在实现数据的参考完整性方面，可以加速表和表之间的连接
  • 对于有依赖关系的子表和父表联合查询时，可以提高查询速度
• 在使用分组和排序子句进行数据查询是，可以显著减少查询中分组和排序的时间，降低CPU的消耗

1.3、缺点

• 创建索引和维护索引要消耗时间，并且随着数据量的增加，所消耗的时间也会增加
• 索引需要占用磁盘空间，除了数据表占数据空间之外，每一个索引还要占用一定的物理空间，存储在磁盘上
  • 如果有大量的索引，索引文件就可能比数据文件更快达到最大文件尺寸
• 虽然索引大大提高了查询数据，同时却会降低更新表的速度
  • 当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度

提示：索引可以提高查询的速度，但是会影响插入记录的速度。这种情况下，建议先删除表中的索引，然后插入数据，插入完成后在创建索引。

二、设计一个简易的索引

建一个表：

CREATE TABLE index_demo(
	c1 INT,
	c2 INT,
	c3 CHAR(1),
	PRIMARY KEY(c1)
) ROW_FORMAT = Compact;

??这个新建的 index_demo 表中有2个INT类型的列，1个CHAR(1)类型的列，而且我们规定了c1列为主键，这个表使用 Compact 行格式来实际存储记录的。这里我们简化了index_demo表的行格式示意图：

• record_type：记录头信息的一项属性，表示记录的类型，0表示普通记录、1表示目录项记录、2表示最小记录、3表示最大记录
• next_record：记录头信息的一项属性，表示下一条地址相对于本条记录的地址偏移量
  • 这里，我们用箭头来表明下一条记录
• 各个列的值：只记录在表中的列
• 其他信息：除了上述3种信息以外的所有信息，包括其他隐藏列的值以及记录的额外信息。

插入数据

INSERT INTO index_demo values(1,2,'a'),(3,4,'b'),(5,6,'c');

这里假设存放普通用户记录的数据页和存放目录项记录的数据页都只能放3条记录

下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。

目录项记录和普通的用户记录的不同点：

• 目录项记录的record_type值是1，而普通用户记录的record_type值是0
• 目录项记录只有主键值和页的编号两个列，而普通的用户记录的列是用户自己定义的，可能包含很多列，另外还有InnoDB自己添加的隐藏列。
• 记录头信息里还有一个min_rec_mask的属性，只有在存储目录项记录的页中的主键值最小的目录项记录的 min_rec_mask值为1 ，其他别的记录的min_rec_mask值都是0。

目录项记录和普通的用户记录的相同点：

• 两者用的是一样的数据页，都会为主键值生成Page Directory（页目录），从而在按照主键值进行查找时可以使用二分法来加快查询速度。

二、常见索引概念

??索引按照物理实现方式，索引可以分为2种：聚簇（聚集）和非聚簇（非聚集）索引。我们也把非聚集索引称为二级索引或者辅助索引。

2.1、 聚簇索引

??聚合索引并不是一种单独的索引类型，而是一种数据存储方式（所有的用户记录都存储在了叶子节点），也就是所谓的索引即数据，数据即索引。

特点：

• 使用记录主键值的大小进行记录和页的排序，这包括三个方面的含义：
  • 页内的记录是按照主键的大小顺序排成一个单向链。
  • 各个存放用户记录的页也是根据页中用户记录的主键大小顺序排成一个双向链表。
  • 存放目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的主键大小顺序排成一个双向链表。
• B+树的叶子节点存储的是完整的用户记录。
  • 所谓完整的用户记录，就是指这个记录中存储了所有列的值（包括隐藏列）。

??我们把具有这两种特性的B+数称为聚簇索引，所有完整的用户记录都存放在这个聚簇索引的叶子节点出。这种聚簇索引并不需要我们在MySQL语句中显示的使用INDEX语句去创建，InnoDB存储引擎会自动的为我们创建聚簇索引。

优点：

• 数据访问更快，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更快。
• 聚簇索引对于主键的排序查找和范围查找速度非常快。
• 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以节省了大量的io操作。

缺点：

• 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。
  • 因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键。
• 更新主键的代价很高，因为将会导致被更新的行移动。
  • 因此，对于InnoDB表，我们一般定义主键为不可更新
    -二级索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据

限制：

• 对于MySQL数据库目前只有InnoDB数据引擎支持聚簇索引，而MyISAM并不支持聚簇索引。
• 由于数据物理存储排序方式只能有一种，所以每个MySQL的表只能有一个聚簇索引。
  • 一般情况下就是该表的主键
• 如果没有定义主键，InnoDB会选择非空的唯一索引代替。
  • 如果没有这样的索引，InnoDB会隐式的定义一个主键来作为聚簇索引
• 为了充分利用聚簇索引的聚簇的特性，所以InnoDB表的主键尽量选用有序的顺序id，而不建议用无序的id。

2.2、二级索引（辅助索引、非聚簇索引）

??聚簇索引只能在搜索条件是主键值时才能发挥作用，因为B+树中的数据都是按照主键进行排序的。如果我们想以别的列作为搜索条件时，可以多建几颗B+树，不同的B+树中的数据采用不同的排序规则。

??我们根据这个以c2列大小排序的B+树只能确定我们要查找记录的主键值，所以如果我们想根据c2列的值查找到完整的用户记录的话，仍然需要到聚簇索引中再查一遍，这个过程称为回表。也就是根据c2列的值查询一条完整的用户记录需要使用到2棵B+树！如果把完整的用户记录放到叶子节点中是可以不用回表，但是太浪费存储空间了，这相当于每建立一课B+树都需要把所有的用户记录在拷贝一遍。因为这种按照非主键列建立B+树需要一次回表操作才可以定位到完整的用户记录，所以这种B+树也称为二级索引（secondary index），或者辅助索引。非聚簇索引的存在不影响数据在聚簇索引中的组织，所以一张表可以有多个非聚簇索引。

2.3、联合索引

??我们可以同时以多个列的大小作为排序规则，也就是同时为多个列建立索引。比方说我们想让B+树按照c2和c3列的大小进行排序，这个包含两层含义：先把各个记录和页按照c2列进行排序，在记录的c2列相同的情况下，采用c3列进行排序。以c2和c3列的大小为排序规则建立的B+树称为联合索引，本质上也是一个二级索引。它的意思与分别为c2和c3列分别建立索引的表述是不同的，不同点如下：建立联合索引只会建立如上图一样的1棵B+树。为c2和c3列分别建立索引会分别以c2和c3列的大小为排序规则建立2棵B+树。

三、InnoDB的B+树索引的注意事项

1、根页面位置万年不动

??每当为某个表创建一个B+树索引（聚簇索引不是人为创建的，默认就有）的时候，都会为这个索引创建一个根节点页面。最开始的时候表中没有数据的时候，每个B+树索引对应的根节点中既没有用户记录，也没有目录项记录。随后，向表中添加插入用户记录时，先把用户记录存储到这个根节点中。当根节点的可用空间用完时继续插入记录，此时会将根节点中的所有记录复制到一个新分配的也，比如页a，然后对这个新页进行页分裂的操作，得到另一个新页，比如页b。这是新插入的记录根据键值（也就是聚簇索引中的主键值，二级索引中对应的索引列的值）的大小就会被分配到页a或者页b中，而根节点便升级为存储目录项记录的页。

??一个B+树索引的根节点自诞生之日起，便不会再移动。这样，只要我们对某个表建立一个索引，那么它的根节点的页号便会被记录到某个地方，然后凡是InnoDB存储引擎需要用到这个索引的时候，都会从那个固定的地方取出根节点的页号，从而访问这个索引。

2、内节点中目录项记录的唯一性

3.一个页面最少存储2条记录

四、MyISAM中索引方案

??MyISAM的索引方案虽然也使用树形结构，但是却将索引和数据分开存储；将表中的记录按照记录的插入顺序单独存储再一个文件中，称之为数据文件。这个文件并不划分为若干个数据页，有多少记录就往这个文件中塞多少条记录。由于在插入数据的时候并没有刻意按照主键大小排序，所以我们并不能在这些数据上使用二分法进行查找。使用MyISAM存储引擎的表会把索引信息另外存储到一个称为索引文件的另一个文件中。MyISAM会单独为表的主键创建一个索引，只不过在索引的叶子节点中存储的不是完整的用户记录，而是主键值+数据记录地址的组合。

五、MyISAM 与 InnoDB对比

• 在InnoDB存储引擎中，我们只需要根据主键值对聚簇索引进行一次查找就能找到对应的记录，而在MyISAM中却需要进行一次回表操作，意味着MyISAM中建立的索引相当于全部都是二级索引。
• InnoDB的数据文件本身就是索引文件，而MyISAM索引文件和数据文件是分离的 ，索引文件仅保存数据记录的地址。
• InnoDB的非聚簇索引data域存储相应记录主键的值，而MyISAM索引记录的是地址。
  • InnoDB的所有非聚簇索引都引用主键作为data域。
• MyISAM的回表操作是十分快速的，因为是拿着地址偏移量直接到文件中取数据的，反观InnoDB是通过获取主键之后再去聚簇索引里找记录，虽然说也不慢，但还是比不上直接用地址去访问。
• InnoDB要求表必须有主键（ MyISAM可以没有 ）。
  • 如果没有显式指定，则MySQL系统会自动选择一个可以非空且唯一标识数据记录的列作为主键。
  • 如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整型。

六、索引的代价

空间上的代价：
??每建立一个索引都要为它建立一棵B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会占用16KB的存储空间，一棵很大的B+树由许多数据页组成，那就是很大的一片存储空间。

时间上的代价：
??每次对表中的数据进行增、删、改 操作时，都需要去修改各个B+树索引。B+树每层节点都是按照索引列的值从小到大的顺序排序而组成了双向链表。不论是叶子节点中的记录，还是内节点中的记录（也就是不论是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序而形成了一个单向链表。而增、删、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需要额外的时间进行一些记录移位，页面分裂、页面回收等操作来维护好节点和记录的排序。如果我们建了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿。

七、MySQL数据结构选择的合理性

??从MySQL的角度将，不得不考虑一个现实问题就是磁盘IO。如果我们能让索引的数据结果尽量减少磁盘I/O操作，所消耗的时间也就越少。可以说，磁盘I/O操作次数对索引的使用效率至关重要。查找都是索引操作，一般来说索引非常大，尤其时关系型数据库，当数据库比较大的时候，索引的大小有可能几个G甚至更多，为了减少索引在内存的占用，数据库索引是存储在外部磁盘上的。当我们利用索引查询的时候，不可能把整个索引全部加载到内存，只能逐一加载，那么MySQL衡量查询效率的标准就是磁盘IO次数。

7.1、Hash结构

??Hash本身就是一个函数，有被称为散列函数，它可以帮助我们答复提升检索的效率。Hash算法是通过某种确定性的算法将输入转变为输出。相同的输入永远可以得到相同的输出，假设输入内容有微小偏差，在输出结果中通常会有不同的结果。哈希函数有可能将两个不同的关键字映射到相同的位置，这叫做碰撞，在数据库中一般采用链接法来解决。在链接法中，将散列到同一槽位的元素放在一个链表中。

??Hash索引仅能满足 =、<> 和 IN 查询。如果进行范围查找，哈希值的索引，时间复杂度会退化为O(n)；而树型的“有序”特性，依然能保持O(log2N)的高效率。Hash索引还有一个缺陷，数据的存储是没有顺序的，在ORDER BY 的情况下，使用Hash索引还需要对数据进行重新排序。对于联合索引的情况，Hash值是将联合索引键合并后一起计算的，无法对单独的一个键或者几个索引键进行查询。对于等值查询来说，通常Hash索引的效率更高，不过也存在一种情况，就是索引列的重复值如果很多，效率就会降低。这是因为遇到Hash冲突是，需要遍历桶中的行指针来进行比较，找到查询的关键字，非常耗时。所以，Hash索引通常不会用到重复值多的列上。

Hash索引适用存储引擎

InnoDB本身不支持Hash索引，但是提供自适应 Hash 索引（Adaptive Hash Index）。如果某个数据经常被访问，当满足一定条件的时候，就会将这个数据页的地址存放到Hash表中。这样下次查询的时候，就可以直接找到这个页面的所在位置。这样让B+树也具备了Hash索引的优点。

7.2、树形结构

7.2.1、二叉搜索树

1.二叉搜索树的特点：

• 一个节点只能有两个子节点，也就是一个节点度不能超过2
• 左子节点 < 本节点；右子节点 >= 本节点；比我小的向左，比我大的向右；

2.查找规则：

• 假设搜索插入的数值为key
  • 如果key小于本节点，则在左子树中进行查找；
  • 如果key大于本节点，则在右子树中进行查找；
  • 如果key等于本节点，也就是找到了这个节点，返回根节点即可；

7.2.2、AVL树

??平衡二叉搜索树（Balanced Binary Tree），又称为AVL树，它在二叉搜索树的基础上增加了约束，具有以下性质：它是一个空树或者它的左右两个字数的高度差的绝对值不超过1，并且左右两个子树都是一颗平衡二叉树.

7.2.3、B-Tree

??B树的英文是Balance Tree，也就是多路平衡查找树，简称B-Tree。它的高度远小于平衡二叉树的高度。B树作为多路平衡二叉树，它的每一个节点最多可以包括M个子节点，M称为B树的阶。每个磁盘块中包括了关键字和子节点的指针。如果一个磁盘块中包括了x个关键字，那么指针数就是x+1。

一个M阶的B树（M>2）具有以下特性：

• 根节点的儿子数的范围是[2,M]
• 每个中间节点包含k-1个关键字和k个孩子，孩子的数量=关键字的数量+1，k的取值为[ceil(M/2),M]
• 叶子节点包括k-1个关键字（叶子节点没有孩子），k的取值范围为[ceil(M/2),M]
• 假设中间节点节点的关键字为：Key[1],Key[2],...,Key[k-1]，且关键字按照升序排序，即Key[i] < Key[i+1]。
  • 此时，k-1个关键字相当于划分了k个范围，也就是对应着k个指针；即为：P[1],P[2],...,P[k]，其中P[1]指向关键字小于Key[1]的子树，P[i]指向关键字属于(Key[i-1],Key[i])的子树，P[k]指向关键字大于Key[k-1]的子树。
• 所有叶子节点位于同一层

小结：

• B树在插入和删除节点的时候如果导致树不平衡，就通过自动调整节点的位置来保持树的自平衡
• 关键字集合分布在整棵树中，即叶子节点和非叶子节点都存放数据，搜索有可能在非叶子节点结束
• 其搜索性能等价于在关键字全集内做一次二叉查找

7.2.3、B+树

??B+树也是一种多路搜索树，基于B树做出了改进，主要的DBMS都支持B+树的索引方式。相比于B-Tree，B+Tree适合文件索引系统。

B+ 树和 B 树的差异：

• 有k个孩子的节点就有k个关键字。也就是孩子数量=关键字数。而B树中，孩子数量=关键字数+1。
• 非叶子节点的关键字也会同时存在在子节点中，并且是在子节点中所有关键字的最大（或最小）。
• 非叶子节点仅用于索引，不保存数据记录，跟记录有关的信息都放在叶子节点中。而B树中，非叶子节点既保存索引，也保存数据记录 。
• 所有关键字都在叶子节点出现，叶子节点构成一个有序链表，而且叶子节点本身按照关键字的大小从小到大顺序链接。

B+树对比B树有什么好处：

• B+树查询效率更稳定
  • 因为B+树每次只有访问到叶子节点才能找到对应的数据，而在B树中，非叶子节点也会存储数据，这样就会造成查询效率不稳定的情况，有时候访问到了非叶子节点就可以找到关键字，而有时需要访问到叶子节点才能找到关键字
• B+树的查询效率更高
  • 因为B+树比B树更矮胖（阶数更大，深度更低），查询所需要的磁盘I/O也会更少。同样的磁盘页大小，B+树可以存储更多的节点关键字
• 在查找范围上，B+树的效率也比B树高
  • 因为所有关键字都出现在B+树的叶子节点中，叶子节点之间会有指针，数据又是递增的，这使范围查找可以通过指针连接查找。而B树种则需要通过中序遍历才能完成查询范围的查找，效率要低很多。