详解MySQL-InnoDB中索引与算法

引言

索引在应用程序设计和开发中是一个重要的方面。往往实际开发中部分工程师对其重视或认知程度不足，忽略索引的重要性，导致要么不用索引，要么滥用索引，这样都会对系统性能产生影响。博主对索引这部分知识进行了总结和归纳，其中也附加自己的认知，分享给大家一起讨论和理解。

为何用索引

大家仔细想想是不是大部分的系统读占比很大，而且在生产环境中，最容易出问题也是复杂的查询操作，这都是源自于一条条的SQL，SQL优化就成为重中之重，这其中索引起到非常关键作用。

索引是什么

索引在MySQL中也叫做“键”或者"key"（primary key，unique key，还有一个index key），是存储引擎用于快速找到记录的一种数据结构。索引对于良好的性能非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要，减少io次数，加速查询。索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。
强调：一旦为表创建了索引，以后的查询最好先查索引，再根据索引定位的结果去找数据

索引的认知

站在开发者的角度：在系统设计之初就要考虑索引的设计

认识索引

认识

​索引的目的在于提高查询效率，结合生活中的案例，其实与查阅图书是一个道理：先定位到章，然后定位到该章下的一个小节，然后找到页数。相似的例子还有：查字典，查火车车次，飞机航班等。仔细思考，书的目录占不占页数，这个页是不是也要存到硬盘里面，也占用硬盘空间。你再想，你在没有数据的情况下先建索引或者说目录快，还是已经存在好多的数据了，然后再去建索引，哪个快，肯定是没有数据的时候快，因为如果已经有了很多数据了，你再去根据这些数据建索引，是不是要将数据全部遍历一遍，然后根据数据建立索引。你再想，索引建立好之后再添加数据快，还是没有索引的时候添加数据快，索引是用来干什么的，是用来加速查询的，那对你写入数据会有什么影响，肯定是慢一些了，因为你但凡加入一些新的数据，都需要把索引或者说书的目录重新做一个，所以索引虽然会加快查询，但是会降低写入的效率。

影响

• 在表中有大量数据的前提下，创建索引速度会很慢
• 在索引创建完毕后，对表的查询性能会大幅度提升，但是写性能会降低

本质：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。

数据库也是一样，但显然要复杂的多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段…这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的。而数据库实现比较复杂，一方面数据是保存在磁盘上的，另外一方面为了提高性能，每次又可以把部分数据读入内存来计算，因为我们知道访问磁盘的成本大概是访问内存的十万倍左右，所以简单的搜索树难以满足复杂的应用场景。

磁盘IO与预读

​前面提到了访问磁盘，那么这里先简单介绍一下磁盘IO和预读。磁盘读取数据靠的是机械运动，每次读取数据花费的时间可以分为寻道时间、旋转延迟、传输时间三个部分，寻道时间指的是磁臂移动到指定磁道所需要的时间，主流磁盘一般在5ms以下；旋转延迟就是我们经常听说的磁盘转速，比如一个磁盘7200转/min，表示每分钟能转7200次，也就是说1秒钟能转120次，旋转延迟就是1/120/2 = 4.17ms，也就是半圈的时间（这里有两个时间：平均寻道时间，受限于目前的物理水平，大概是5ms的时间，找到磁道了，还需要找到你数据存在的那个点，寻点时间，这寻点时间的一个平均值就是半圈的时间，这个半圈时间叫做平均延迟时间，那么平均延迟时间加上平均寻道时间就是你找到一个数据所消耗的平均时间，大概9ms，其实机械硬盘慢主要是慢在这两个时间上了，当找到数据然后把数据拷贝到内存的时间是非常短暂的，和光速差不多了）；传输时间指的是从磁盘读出或将数据写入磁盘的时间，一般在零点几毫秒，相对于前两个时间可以忽略不计。那么访问一次磁盘的时间，即一次磁盘IO的时间约等于5+4.17 = 9ms左右，听起来还挺不错的，但要知道一台500 -MIPS（Million Instructions Per Second）的机器每秒可以执行5亿条指令，因为指令依靠的是电的性质，换句话说执行一次IO的消耗的时间段下cpu可以执行约450万条指令，数据库动辄十万百万乃至千万级数据，每次9毫秒的时间，显然是个灾难，所以我们要想办法降低IO次数。

数据结构和算法

在此之前我们先简单了解一下InnoDB存储引擎支持的索引，InnoDB存储引擎支持以下几种常见的索引：

• B+树索引
• 全文索引
• 哈希索引

B+树索引是关系型数据库中查找最为常用和最为有效的索引。其中涉及很多的算法和数据结构，先认识一下相关的知识，这更加有助于我们理解B+树的工作方式。

二分查找法

也称其为折半查找法，前提是数据已经是有序的状态，将数据分割成两等份，再比较键值与中间值的大小，如果键值小于中间值，确定查找的数据在前半段，否则在后半段。通过一次次的比较，将查找区间缩小一半。时间复杂度为O(logn)。
代码实现：https://blog.csdn.net/qq_36581961/article/details/112203684

二叉查找树、红黑树和平衡二叉树

二叉查找树：
在二叉查找树中，左子树的键值总是小于根的键值，右子树的键值总是大于根的键值，具体的实现过程可以参考https://www.cs.usfca.edu/~galles/visualization/BST.html。二叉查找树可以任意构造，当出现递增的情况，查找的次数回提高，和顺序查找差不多，类似于链表，这时查询效率降低。

红黑树：
构建过程可以参考https://www.cs.usfca.edu/~galles/visualization/RedBlack.html，在JDK1.8中HashMap底层使用就是红黑树，它的特点就是有自旋的功能，能够避免出现二叉查找树中递增的现象。但是当数据量过大时，会造成树的高度过高，也会降低查询效率。

平衡二叉树
定义：首先要符合二叉树的定义，其次必须满足任何节点的两个子树的高度最大差为1。实现过程https://www.cs.usfca.edu/~galles/visualization/AVLtree.html，平衡二叉树的查询速度很快，但是维护一棵平衡二叉树的代价是比较大的，因为需要大量的旋转操作。

B+树

关于b+树的定义：B+树是为磁盘或其他直接存取辅助设备设计的一种平衡查找树，在B+树中，所有记录节点都是按键值的大小存放在同一层的叶子节点上，由个叶子节点指针进行连接。(这只是精简介绍，具体内容可以自行百度)

​如图：点击查看图片，是一颗b+树，最上层是树根，中间的是树枝，最下面是叶子节点。

如上图：浅蓝色的块我们称之为一个磁盘块或者叫做一个block块，这是操作系统一次IO往内存中读的内容，一个块对应3个扇区，可以看到每个磁盘块包含几个数据项（深蓝色所示，一个磁盘块里面包含多少数据，一个深蓝色的块表示一个数据，其实不是数据，后面有解释）和指针（黄色所示，看最上面一个，p1表示比上面深蓝色的那个17小的数据的位置在哪，看它指针指向的左边那个块，里面的数据都比17小，p2指向的是比17大比35小的磁盘块），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。

b+树的查找过程：如图所示，如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。除了叶子节点，其他的树根啊树枝啊保存的就是数据的索引，他们是为你建立这种数据之间的关系而存在的。

b+树性质

• 索引字段要尽量的小
  ​通过上面的分析，我们知道IO次数取决于b+数的高度h或者说层级，这个高度或者层级就是你每次查询数据的IO次数，假设当前数据表的数据为N，每个磁盘块的数据项的数量是m，则有h=㏒(m+1)N，当数据量N一定的情况下，m越大，h越小；而m = 磁盘块的大小 / 数据项的大小，磁盘块的大小也就是一个数据页的大小，是固定的，如果数据项占的空间越小，数据项的数量越多，树的高度越低。这就是为什么每个数据项，即索引字段要尽量的小，比如int占4字节，要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点，一旦放到内层节点，磁盘块的数据项会大幅度下降，导致树增高。当数据项等于1时将会退化成线性表。

• 索引的最左匹配特性
  简单来说就是你的数据来了以后，从数据块的左边开始匹配，在匹配右边的，知道这句话就行啦~~~~，我们继续学下面的内容。当b+树的数据项是复合的数据结构，比如(name,age,sex)的时候，b+数是按照从左到右的顺序来建立搜索树的，比如当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是F的数据了， 这个是非常重要的性质，即索引的最左匹配特性。

聚集索引和辅助索引

还记得MyISAM存储引擎在创建表的时候会在硬盘上生成哪些文件吗，是不是有三个.frm.MYD.MYI结尾的三个文件，frm结尾的是表结构，MYD结尾的是数据文件，MYI结尾的就是索引文件，也就是说索引也是存在硬盘上的，那InnoDB引擎呢，创建一个表，在硬盘上会生成.frm.idb 结尾的两个文件，那索引的呢，难道InnoDB就用不了索引吗？怎么可能？之前咱们有没有建立过索引啊，primary key、unique key是不是都叫做索引啊，但是索引那个文件去哪了呢，索引是不可能在表结构.frm（存什么字段什么类型这些东西）的文件中，那就只剩下.idb结尾的数据文件了，索引就在这里面，InnoDB引擎的表，它的索引和数据都在同一个文件里面，所以一直强调，使用InnoDB存储引擎的时候，每建一个表，就需要给一个主键，是因为这个主键是InnoDB存储引擎的.idb文件来组织存储数据的依据或者说方式。

也就是说InnoDB存储引擎在存储数据的时候默认就按照索引的那种树形结构来帮你存。这种索引，我们就称为聚集索引，也就是在聚集数据组织数据的时候，就用这种索引。InnoDB这么做就是为了加速查询效率，因为你经常会遇到基于主键来查询数据的情况，并且通常我们把id字段作为主键，第一点是因为id占用的数据空间不大，第二点是你经常会用到id来查数据。如果你的表有两个字段，一个id一个name，id为主键，当你查询的时候如果where后面的条件是name=多少多少，那么你就没有用到主键给你带来的加速查询的效果（需要主键之外的辅助索引），如果你用where id=多少多少，就会按照我们刚才上面说的哪种树形结构来给你找寻数据了（当然不仅仅有这种树形结构的数据结构类型），能够快速的帮你定位到数据块。这种聚集索引的特点是它会以id字段作为依据，去建立树形结构，但是叶子节点存的是你表中的一条完整记录，一条完整的数据。记住这一点昂，辅助索引和这个内容有关系，会讲到一个回表的概念。

---

​在数据库中，B+树的高度一般都在2-4层，这也就是说查找某一个键值的行记录时最多只需要2到4次IO，这倒不错。因为当前一般的机械硬盘每秒至少可以做100次IO，2-4次的IO意味着查询时间只需要0.02~0.04秒。

数据库中的B+树索引可以分为聚集索引（clustered index）和辅助索引（secondary index），聚集索引与辅助索引相同的是：不管是聚集索引还是辅助索引，其内部都是B+树的形式，即高度是平衡的，叶子结点存放着所有的数据。聚集索引与辅助索引不同的是：叶子结点存放的是否是一整行的信息

聚集索引

​InnoDB存储引擎表示索引组织表，即表中数据按照主键顺序存放。而聚集索引（clustered index）就是按照每张表的主键构造一棵B+树，同时叶子结点存放的即为整张表的行记录数据，也将聚集索引的叶子结点称为数据页。

聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。同B+树数据结构一样，每个数据页都通过一个双向链表来进行链接。 如果未定义主键，MySQL取第一个唯一索引（unique）而且只含非空列（NOT NULL）作为主键，InnoDB使用它作为聚簇索引。如果没有这样的列，InnoDB就自己产生一个这样的ID值，它有六个字节，而且是隐藏的，使其作为聚簇索引。 由于实际的数据页只能按照一棵B+树进行排序，因此每张表只能拥有一个聚集索引。在多少情况下，查询优化器倾向于采用聚集索引。因为聚集索引能够在B+树索引的叶子节点上直接找到数据。此外由于定义了数据的逻辑顺序，聚集索引能够特别快地访问针对范围值得查询。

聚集索引的优点
它对主键的排序查找速度非常快，叶子节点的数据就是用户所要查询的数据。如用户需要查找一张表，查询最后的10位用户信息，由于B+树索引是双向链表，所以用户可以快速找到最后一个数据页，并取出10条记录；范围查询（range query），即如果要查找主键某一范围内的数据，通过叶子节点的上层中间节点就可以得到页的范围，之后直接读取数据页即可

辅助索引

表中除了聚集索引外其他索引都是辅助索引（Secondary Index，也称为非聚集索引）（unique key啊、index key啊），与聚集索引的区别是：辅助索引的叶子节点不包含行记录的全部数据。

​叶子节点存放的是对应的那条数据的主键字段的值，除了包含键值以外，每个叶子节点中的索引行中还包含一个书签（bookmark），其实这个书签你可以理解为是一个{‘name字段’，name的值，主键id值}的这么一个数据。该书签用来告诉InnoDB存储引擎去哪里可以找到与索引相对应的行数据。如果我们select 后面要的是name，我们直接就可以在辅助索引的叶子节点找到对应的name值，比如：select name from tb1 where name=‘xx’；这个xx值你直接就在辅助索引的叶子节点就能找到，这种我们也可以称为[覆盖索引]。如果你select后面的字段不是name，例如：select age from tb1 where name=‘xx’；也就是说，我通过辅助索引的叶子节点不能直接拿到age的值，需要通过辅助索引的叶子节点中保存的主键id的值再去通过聚集索引来找到完整的一条记录，然后从这个记录里面拿出age的值，这种操作有时候也成为[回表查询]，就是从头再回去查一遍，这种的查询效率也很高，但是比覆盖索引低一些，再说一下昂，再辅助索引的叶子节点就能找到你想找的数据可称为[覆盖索引]。

联合索引和索引覆盖

联合索引

联合索引时指对表上的多个列合起来做一个索引，省的你查询的时候，where后面的条件字段一直再变，你就想给每个字段加索引的尴尬问题。联合索引的创建方法与单个索引的创建方法一样，不同之处在仅在于有多个索引列.

注意建立联合索引的一个原则： 索引是有个最左匹配的原则的，所以建联合索引的时候，将区分度高的放在最左边，依次排下来，范围查询的条件尽可能的往后边放。

联合索引的第二个好处是在第一个键相同的情况下，已经对第二个键进行了排序处理， 例如在很多情况下应用程序都需要查询某个用户的购物情况，并按照时间进行排序，最后取出最近三次的购买记录，这时使用联合索引可以帮我们避免多一次的排序操作，因为索引本身在叶子节点已经排序了

索引覆盖

InnoDB存储引擎支持覆盖索引（covering index，或称索引覆盖），即从辅助索引中就可以得到查询记录，而不需要查询聚集索引中的记录。

使用覆盖索引的一个好处是：辅助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的IO操作

注意：覆盖索引技术最早是在InnoDB Plugin中完成并实现，这意味着对于InnoDB版本小于1.0的，或者MySQL数据库版本为5.0以下的，InnoDB存储引擎不支持覆盖索引特性

对于InnoDB存储引擎的辅助索引而言，由于其包含了主键信息，因此其叶子节点存放的数据为（primary key1，priamey key2，…,key1，key2，…）

索引管理

普通索引INDEX：加速查找 
	唯一索引：
        -主键索引PRIMARY KEY：加速查找+约束（不为空、不能重复） 
        -唯一索引UNIQUE:加速查找+约束（不能重复） 
	联合索引： 
		-PRIMARY KEY(id,name):联合主键索引 
        -UNIQUE(id,name):联合唯一索引 
        -INDEX(id,name):联合普通索引
索引操作：
	添加主键索引:
	创建的时候添加:添加索引的时候要注意,给字段里面数据大小比较小的字段添加,给字段里面的数据区分度高的字段添加.
聚集索引的添加方式
	创建的是添加
        Create table t1(
        Id int primary key,
        )
        Create table t1(
        Id int,
        Primary key(id)
        )
	表创建完了之后添加
		Alter table 表名 add primary key(id)
	删除主键索引:
		Alter table 表名 drop primary key;
	
	唯一索引:
        Create table t1(
        Id int unique,
        )
            Create table t1(
        Id int,
        Unique key uni_name (id)
        )
		表创建好之后添加唯一索引:
			alter table s1 add unique key  u_name(id);
    	删除:
    		Alter table s1 drop index u_name;
    	
	普通索引:
        创建:
            Create table t1(
            Id int,
            Index index_name(id)
            )
            Alter table s1 add index index_name(id);
            Create index index_name on s1(id);
        删除:
            Alter table s1 drop index u_name;
            DROP INDEX 索引名 ON 表名字;
	举个例子来说，比如你在为某商场做一个会员卡的系统。 这个系统有一个会员表 有下列字段： 
		会员编号 INT 
		会员姓名 VARCHAR(10) 
		会员身份证号码 VARCHAR(18) 
		会员电话 VARCHAR(10) 
		会员住址 VARCHAR(50) 
		会员备注信息 TEXT
	那么这个 
		会员编号，作为主键，使用 PRIMARY 
		会员姓名 如果要建索引的话，那么就是普通的 INDEX 
		会员身份证号码 如果要建索引的话，那么可以选择 UNIQUE （唯一的，不允许重复）
	#除此之外还有全文索引，即FULLTEXT 
		会员备注信息 ， 如果需要建索引的话，可以选择全文搜索。 
		用于搜索很长一篇文章的时候，效果最好。 
		用在比较短的文本，如果就一两行字的，普通的 INDEX 也可以。 
		但其实对于全文搜索，我们并不会使用MySQL自带的该索引，而是会选择第三方软件如Sphinx，专门来做全文搜索。 
#其他的如空间索引SPATIAL，了解即可，几乎不用

正确使用索引

• 范围问题，或者说条件不明确，条件中出现这些符号或关键字：**>、>=、<、<=、!= 、between…and…、like、大于号、小于号

• 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录

• =和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式

• 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’)

• and/or

#1、and与or的逻辑 条件1 and 条件2:所有条件都成立才算成立，但凡要有一个条件不成立则最终结果不成立 条件1 or 条件2:只要有一个条件成立则最终结果就成立

#2、and的工作原理 条件： a = 10 and b = ‘xxx’ and c > 3 and d =4 索引： 制作联合索引(d,a,b,c)
工作原理: #如果是你找的话，你会怎么找，是不是从左到右一个一个的比较啊，首先你不能确定a这个字段是不是有索引，即便是有索引，也不一定能确保命中索引了（所谓命中索引，就是应用上了索引），mysql不会这么笨的，看下面mysql是怎么找的： 索引的本质原理就是先不断的把查找范围缩小下来，然后再进行处理，对于连续多个and：mysql会按照联合索引，从左到右的顺序找一个区分度高的索引字段(这样便可以快速锁定很小的范围)，加速查询，即按照d—>a->b->c的顺序

#3、or的工作原理 条件： a = 10 or b = ‘xxx’ or c > 3 or d =4 索引： 制作联合索引(d,a,b,c) 工作原理: 只要一个匹配成功就行，所以对于连续多个or：mysql会按照条件的顺序，从左到右依次判断，即a->b->c->d

• 最左前缀匹配原则，非常重要的原则，对于组合索引mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配(指的是范围大了，有索引速度也慢)，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

其他情况

- 使用函数
   select * from tb1 where reverse(email) = 'egon';
       
- 类型不一致
   如果列是字符串类型，传入条件是必须用引号引起来，不然...
   select * from tb1 where email = 999;

#排序条件为索引，则select字段必须也是索引字段，否则无法命中
- order by
   select name from s1 order by email desc;
   当根据索引排序时候，select查询的字段如果不是索引，则速度仍然很慢
   select email from s1 order by email desc;
   特别的：如果对主键排序，则还是速度很快：
     select * from tb1 order by nid desc;

- 组合索引最左前缀
   如果组合索引为：(name,email)
   name and email    -- 命中索引
   name         -- 命中索引
   email        -- 未命中索引

- count(1)或count(列)代替count(*)在mysql中没有差别了

- create index xxxx on tb(title(19)) #text类型，必须制定长度

注意事项

避免使用select -
count(1)或count(列) 代替 count()
创建表时尽量时 char 代替 varchar
表的字段顺序固定长度的字段优先
组合索引代替多个单列索引（经常使用多个条件查询时）
尽量使用短索引
使用连接（JOIN）来代替子查询(Sub-Queries)
连表时注意条件类型需一致
索引散列值（重复少）不适合建索引，例：性别不适合