【深入学习二】MySQL 索引深度剖析

1. 索引

1.1 索引是什么？

        举个栗子：有一张 user表，里面有 4 个字段，分别是 id、name、gender、phone，当这张表有500 万条数据时，在没有索引的 name字段上执行一句查询，如：

select * from user where name = '张三';

我们观察一下 SQL 查询的执行时间。

如果我们在name 字段上建立索引，然后再重新执行一下上面的 SQL 语句，再观察一下响应时间，你会惊奇的发现，响应时间变快了，有索引和没有索引的查询响应时间相差了几十倍。那么索引到底是什么呢？为什么加了索引查询效率就提高了呢？创建索引的时候又做什么事情呢？下面我们来进行详细说明。

1.1.1 索引图解

        维基百科对索引的解释：数据库索引，是数据库管理系统(DBMS)中一个排序的数据结构，以协助快速查询、 更新数据库表中数据。

数据是以文件的形式存放在磁盘上面的，每一行数据都有它的磁盘地址。如果没有索引的话，我们要从500万行数据里面检索一条数据，只能依次遍历这张表的全部数据, 直到找到这条数据。但是我们有了索引之后，只需要在索引里面去检索这条数据就行了，因为它是一种特殊的专门用来快速检索的数据结构，我们找到数据存放的磁盘地址以后，就可以拿到数据了。

        就像我们从一本500页的书里面去找特定的一小节的内容，肯定不可能从第一页开始翻。那么这本书有专门的目录，它可能只有几页的内容，它是按页码来组织的，可以根据拼音或者偏旁部首来查找，我们只要确定内容对应的页码，就能很快地找到我们想要的内容。

1.1.2 索引类型

        在 InnoDB里面，索引类型有三种，普通索引、唯一索引（主键索引是特殊的唯一索引）、全文索引。

        普通(Normal)：也叫非唯一索引，是最普通的索引，没有任何的限制。

        唯一 (Unique)：唯一索引要求键值不能重复。另外需要注意的是，主键索引是一种特殊的唯一索引，它还多了一个限制条件，要求键值不能为空。主键索引用 primay key 创建。

        全文(Fulltext)：针对比较大的数据，比如我们存放的是消息内容、一篇文章，有几KB的数据的这种情况，如果要解决like査询在全文匹配的时候效率低的问题，可以创建全文索引。只有文本类型的字段才可以创建全文索引，比如char、varchar、text。

create table testFull
(
    content varchar(500) default null,
    fulltext key content ('content')
);

        MylSAM和InnoDB支持全文索引。

2. 索引存储模型推演

2.1 二分查找

        《幸运52》有一个猜价格的游戏，限定时间之内猜中了就可以带回家。在你报出价格之后主持人会告诉你低了还是高了。如果价格在10000-30000之间，你会先猜多少？

        一般人都会从20000开始猜。其实这个就是二分查找的一种思想，也叫折半查找，每一次，我们都把候选数据缩小了一半。如果数据已经排过序的话，这种方式效率比较高。 所以第一个，我们可以考虑用有序数组作为索引的数据结构。

        有序数组的等值查询和比较查询效率非常高，但是更新数据的时候会出现一个问题, 可能要挪动大量的数据(改变index)，所以只适合存储静态的数据。为了支持频繁的修改，比如插入数据，我们需要采用链表。链表的话，如果是单链表，它的查找效率还是不够高。所以，有没有可以使用二分査找的链表呢？

        为了解决这个问题，BST (Binary Search Tree)也就是我们所说的二叉査找树诞生了。

2.2 二叉树查找（BST Binary Search Tree）

        二叉查找树的特点是什么？

        左子树所有的节点都小于父节点，右子树所有的节点都大于父节点。投影到平面以后，就是一个有序的线性表。

                                                

        二叉查找树既能实现快速查找，又能实现快速插入。

        但是二叉查找树有一个问题：就是他的查找耗时是和这颗树的深度相关的，在最坏的情况下时间复杂度会退化成O(n)。

        什么情况是最坏的情况呢？

        还是刚才的这一批数字，如果我们插入的数据刚好是有序的，44、56、65、87、89、92、99，它就会变成链表（我们把这种树叫做“斜树”），这种情况下，不能达到加快检索速度的目的，和顺序查找效率是没有区别的。

                                              

         造成它倾斜的原因是什么呢？因为左右子树深度差太大，这棵树的左子树根本没有节点——也就是它不够平衡。

        所以，我们有没有左右子树深度相差不是那么大，更加平衡的树呢？这个就是平衡二叉树，叫做Balanced binary search trees，或者AVL树（AVL是发明这个数据结构的两位作者的名字简写：G. M. Adelson-Velsky和E. M. Landis）。

2.3 平衡二叉树（AVL Tree）（左旋、右旋）

        AVL Trees （Balanced binary search trees）
        平衡二叉树的定义：左右子树深度差绝对值不能超过1。是什么意思呢？比如左子树的深度是2，右子树的深度只能是1或者3。这个时候我们再按顺序插入1、2、3、4、5、6,—定是这样，不会变成一棵“斜树”。

                                

        那它的平衡是怎么做到的呢？怎么保证左右子树的深度差不能超过1呢？

        插入1、2、3。我们注意看：当我们插入了 1、2之后，如果按照二叉查找树的定义，3肯定是要在 2的右边的，这个时候根节点1的右节点深度会变成2，但是左节点的深度是0，因为它没有子节点，所以就会违反平衡二叉树的定义。
那应该怎么办呢？因为它是右节点下面接一个右节点，右-右型，所以这个时候我们 要把2提上去，这个操作叫做左旋。

                

 同样的，如果我们插入7、6、5,这个时候会变成左-左型，就会发生右旋操作，把 6 提上去。可以自行进行操作查看演变过程：AVL Tree Visualzation

        所以为了保持平衡，AVL树在插入和更新数据的时候执行了一系列的计算和调整的操作。
平衡的问题我们解决了，那么平衡二叉树作为索引怎么査询数据?在平衡二叉树中，一个节点，它的大小是一个固定的单位，作为索引应该存储什么内容？

        前面我们已经知道了，索引必须要存你建立索引的字段的值，叫做键值，比如id的值。还要存完整记录在磁盘上的地址。由于AVL树是二叉树，所以还要额外地存储左右子树的指针。

                        

        如图：
        第一个是索引的键值。比如我们在id上面创建了一个索引，我在用where id =1的条件查询的时候就会找到索引里面的id的这个键值。
        第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。
        第三个，因为是二叉树，它必须还要有左子节点和右子节点的引用，这样我们才能找到下一个节点。比如大于26的时候，走右边，到下一个树的节点，继续判断。

        如果是这样存储数据的话，我们来看一下会有什么问题。

2.3.1 AVL 树用于存储索引数据

        首先，索引的数据，是放在硬盘上的。查看数据和索引的大小：

select CONCAT(ROUND(SUM(DATA_LENGTH / 1024 / 1024), 2), 'MB')  AS data_len,
       CONCAT(ROUND(SUM(INDEX_LENGTH / 1024 / 1024), 2), 'MB') as index_len
from information_schema.TABLES
where table_schema = 'testdb'
  and table_name = 'user';

        当我们用树的结构来存储索引的时候，访问一个节点就要跟磁盘之间发生一次I/O操作。InnoDB操作磁盘的最小的单位是一页(或者叫一个磁盘块)，大小是16K(16384 字节)。

        那么，一个树的节点必须设计成16K的大小，不然就会出现读不完或者读不够的情况。如果我们一个节点只存一个键值+数据+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远远达不到16K的容量。想象一下，我们基于索引査找数据的时候，肯定是希望一次从磁盘加载很多的数据到内存中进行比较，这样就可以尽快拿到完整的数据。如果一个节点只存1个这样的单元，就需要读更多的节点，发生更多的I/O操作。如果是机械硬盘时代，每次从磁盘读取数据需要10ms左右的寻址时间，交互次数越多，消耗的时间就越多。

                

         比如上面这张图，我们一张表里面有6条数据，当我们查询id = 66的时候，要查询两个子节点，就需要跟磁盘交互3次，如果我们有几百万的数据呢？这个时间更加难以估计。

        我们怎么解决这个问题？
        第一个，就是让每个节点存储更多的数据。
        第二个，节点上的关键字的数量越多，我们的指针数也越多，也就是意味着可以有更多的分叉（我们把它叫做"路数”）。因为分叉数越多，树的深度就会减少（根节点是0）。这样，我们的树是不是从原来的高瘦高瘦的样子，变成了矮胖矮胖的样子？

        这个时候，我们的树就不再是二叉了，而是多叉，或者叫做多路。

2.4 多路平衡查找树（B Tree）(分裂、合并)

        Balanced Tree，这个就是我们的多路平衡查找树，叫做BTree（B代表平衡）。跟AVL树一样，B树在枝节点和叶子节点存储键值、数据地址、节点引用。它有一个特点：分叉数（路数）永远比关键字数多1。比如我们画的这棵树，每个节点存储两个关键字，那么就会有三个指针指向三个子节点（当然肯定不只存3个这么少）。

                                                         

        BTree的查找规则是什么样的呢？

        比如我们要在这张表里面查找15。因为15小于17,走左边。因为15大于12,走右边。在磁盘块7里面就找到了 15,只用了 3次 IO。这个是不是比 AVL树效率更高呢？那B Tree又是怎么实现一个节点存储多个关键字，还保持平衡的呢？跟AVL树有什么区别？

        比如Max Degree (路数)是3的时候，我们插入数据1、2、3,在插入3的时候, 本来应该在第一个磁盘块，但是如果一个节点有三个关键字的时候，意味着有4个指针,子节点会变成4路，所以这个时候必须进行分裂。把中间的数据2提上去，把1和3变 成2的子节点。

                                         

        如果删除节点，会有相反的合并的操作。注意这里是分裂和合并，跟AVL树的左旋和右旋是不一样的。
        我们继续插入4和5, B Tree又会出现分裂和合并的操作。

        从这个里面我们也能看到，在更新索引的时候会有大量的索引的结构的调整，所以解释了为什么我们不要在频繁更新的列上建索引，或者为什么不要更新主键。节点的分裂和合并，其实就是InnoDB页的分裂和合并。如果索引键值有序，写满一页接着开辟一个新的页。如果索引键值无序，存储过程造成大量磁盘碎片，就会带来频繁的page分裂和合并。

2.5 B+树（加强版多路平衡查找树）

        B Tree的效率已经很高了,为什么MySQL还要对B Tree进行改良，最终使用了B+Tree 呢？总体上来说，这个B树的改良版本解决的问题比B Tree更全面。
我们来看一下InnoDB里面的B+树的存储结构：  

                                        

        MySQL中的B+Tree有几个特点：
        1、它的关键字的数量是跟路数相等的；
        2、B+Tree的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。 目前我们的认知：这里要存放的数据是什么？是完整记录的地址。搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索id=28, 虽然在第一层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点。
        3、B+Tree的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数据会指向下一个叶子节点的第一个数据,形成了一个有序链表的结构。

        我们来看一下 B+Tree 的数据搜寻过程：

        1）比如我们要查找 28，在根节点就找到了键值，但是因为它不是叶子节点，所以会继续往下搜寻，28 是[28，66）的左闭右开的区间的临界值，所以会走中间的子节点，然后继续搜索，它又是[28，34）的左闭右开的区间的临界值，所以会走左边的子节点，最后在叶子节点上找到了需要的数据。

        2）第二个，如果是范围查询，比如要查询从22到60的数据，当找到22之后，只需要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高 了区间查询效率（不需要返回上层父节点重复遍历查找）。

        总结一下，InnoDB中的B+Tree特性带来的优势：
        1）它是BTree的变种，BTree能解决的问题，它都能解决。B Tree解决的两大问题是什么？（每个节点存储更多关键字；路数更多）
        2）扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵B+Tree拿到所有的数据）
        3）B+Tree的磁盘读写能力相对于B Tree来说更强（根节点和枝节点不保存数据区, 所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多）
        4）排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链表）
        5）效率更加稳定（B+Tree永远是在叶子节点拿到数据，所以I0次数是稳定的）

        我们举个例子：假设一条记录是［6bytes, 一个叶子节点（一页）可以存储10条记录。非叶子节点可以存储多少个指针？
        假设索引字段 + 指针大小为16字节。非叶子节点（一页）可以存储1000个这样的 单元（键值+指针），代表有1000个指针。
        树深度为 2 的时候，有 1000^2个叶子节点，可以存储的数据为 1000*1000*10 = 10000000（千万级别）。

         在查找数据时一次页的查找代表一次 IO，也就是说，一张千万级别的表，查询数据最多需要访问 3 次磁盘。树的深度是怎么来的？根据你的键值类型和数据量计算出来的。字段值越大、数据量越大，深度越大。所以，在 InnoDB 中 B+ 树深度一般为 1-3 层，它就能够满足千万级的数据存储。

2.6 为什么不用红黑树

        红黑树也是BST树，但是不是严格平衡的，通过变色和旋转来保持平衡。必须满足5个约束：

        1、节点分为红色或者黑色。
        2、根节点必须是黑色的。
        3、叶子节点都是黑色的NULL节点。
        4、红色节点的两个子节点都是黑色（不允许两个相邻的红色节点）。
        5、从任意节点出发，至其每个叶子节点的路径中包含相同数量的黑色节点。  

        比如，我们插入：60、56、68、45、64、 58、72、43、49，可以得到下面的树形结构：

                                                             

        基于以上规则，可以推导出：

        从根节点到叶子节点的最长路径（红黑相间的路径）不大于最短路径（全部是黑色节点）的2倍。

        为什么不用红黑树？ 1、只有两路；2、不够平衡。

        红黑树一般只放在内存里面用。例如Java的TreeMap,它可以用来实现一致性哈希。

3. B+Tree 落地形式

3.1 MySQL 架构

        通过上一篇文章我们得知，MySQL 是一个支持插件式存储引擎的数据库。在 MySQL 里面，每个表在创建的时候，都可以指定它所使用的存储引擎。这里我们关注一下最常使用的两个存储引擎，myisam 和 innodb 的索引的实现。

3.2 MySQL 数据存储文件

        首先，MySQL的数据都是文件的形式存放在磁盘中的，我们可以找到这个数据目录的地址。在MySQL中有这么一个参数，我们来看一下：

show variables like 'datadir';

        

         在服务器找到对应的目录，并找到上面三张表对应的文件，我们可以看到，如下图：

        

        我们发现，使用不同的存储殷勤创建的表，都会有一个 .frm  文件，这个是有存储引擎自动生成的，里面保存的是表结构的定义。这里我们主要看一下其他两个文件是怎么实现 MySQL 不同的存储引擎索引的。我们先来看一下 MyISAM。

3.2.1 MyISAM

        在 MyISAM 里面，另外有两个文件：一个是.MYD文件，D代表Data,是MylSAM的数据文件，存放数据记录，比如我们的user_myisam表的所有的表数据。一个是.MYI文件，I 代表的就是Index,是MylSAM的索引文件，存放索引，比如我们在 id字段上面创建了一个主键索引，那么主键索引就是在这个索引文件里面。一个索引就会有一棵B+Tree,所有的B+Tree都在这个myi文件里面。也就是说，在MylSAM里面，索引和数据是两个独立的文件。

        那我们怎么根据索引找到数据呢？

        MylSAM的B+Tree里面，叶子节点存储的是数据文件对应的磁盘地址。所以从索引文件MYI中找到键值后，会到数据文件.MYD中获取相应的数据记录。

                                                                

        非主键索引和主键索引存储和检索数据的方式是没有任何区别的，一样是在索引文件里面找到磁盘地址，然后到数据文件里面获取数据。这个就是 MyISAM 里面的索引落地的形式。但是在我们的 InnoDB 里面是不一样的。下面我们来看一下。

3.2.2 InnoDB

        在InnoDB的某个索引的叶子节点上，它直接存储了我们的数据。 所以，为什么说在InnoDB中索引即数据，数据即索引，就是这个原因。但是这里会有一个问题，一张InnoDB的表可能有很多个多索引,数据肯定是只有—份的，那数据在哪个索引的叶子节点上呢？

                                                                        

        这里给大家引入一个概念：聚集索引（聚簇索引），就是索引键值的逻辑顺序和表数据行的物理存储顺序是一致的。

        InnoDB组织数据的方式就是（聚集）索引组织表（clustered index organize table）。 如果说一张表创建了主键索引，那么这个主键索引就是聚集索引，决定数据行的物理存储顺序。（比如字典的目录是按拼音排序的，内容也是按拼音排序的，按拼音排序的这种目录就叫聚集索引）。问题来了，那主键索引之外的索引，会不会也把完整记录在叶子节点放一份呢？并不会，因为这会带来额外的存储空间浪费和计算消耗。他们的叶子节点上没有数据怎么检索完整数据？比如我们在name字段上面建的普通索引。

                                                                         

        InnoDB中，主键索引和辅助索引是有一个主次之分的。刚才我们讲了，如果有主键索引，那么主键索引就是聚集索引。其他的索引统一叫做"二级索引”（secondary index）。
二级索引存储的是二级索引的键值，例如在name上建立索引，节点上存的是name 的值，qingshan mic tom等等（很明显，它的键值逻辑顺序跟物理行的顺序不一致）。
而二级索引的叶子节点存的是这条记录对应的主键的值。比如qingshan id = 1, jack id=4...，所以，二级索引检索数据的流程是这样的：当我们用name索引查询一条记录，它会在二级索引的叶子节点找到 name=qingshan,拿到主键值，也就是id = 1,然后再到主键索引的叶子节点拿到数据。
        为什么不存地址而是存键值？因为地址会变化。从这个角度来说，因为主键索引比二级索引少扫描了一棵B+Tree （避免了回表）， 它的速度相对会快一些。

        但是，如果一张表没有主键怎么办？那完整的记录放在哪个索引的叶子节点？或者, 这张表根本没有索引呢？数据放在哪里？
        1、如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择主键作为聚集索引；
        2、如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引；
        3、如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐藏的聚集索引，它会随着行记录的写入而主键递增。

 4. 索引的使用

        我们容易有一个误区，就是在经常使用的查询条件上都建立索引，索引越多越好，那到底是不是这样呢？

4.1 列的离散度

        第一个叫做列的离散度，我们先来看一下列的离散度公式：

                count(distinct (year)):count(*)

        列的全部不同值和所有数据行的比例。数据行数相同的情况下，分子越大，列的离散度就越高。按照这个定义，下图中，name 和 del_flag 的离散度哪个更高呢？

                                                                                

        简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。我们不建议大家在离散度低的字段上建立索引。如果在 B+Tree 里面的重复值太多，MySQL 的优化器发现走索引跟使用全表扫描差不多的时候，就算简历了索引，也不一定会走索引。

4.2 联合索引最左匹配

        前面我们说的都是针对单列创建的索引,但有时候我们的多条件査询，也会建立联合索引。单列索引可以看成是特殊的联合索引。比如我们在user表上面，给name和phone建立了一个联合索引。

ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);

 

        联合索引在B+Tree中是复合的数据结构，它是按照从左到右的顺序来建立搜索树的 （name在左边，phone在右边）。从这张图可以看岀来，name是有序的，phone是无序的。当name相等的时候，phone才是有序的。这个时候我们使用where name = ‘Bob' and phone = '189xx' 去査询数据的时候, B+Tree会优先比较name来确定下一步应该搜索的方向，往左还是往右。如果name相同的时候再比较phoneo，但是如果查询条件没有name,就不知道第一步应该查哪个节点，因为建立搜索树的时候name是第一个比较因子，所以用不到索引。

4.2.1 什么时候用到联合索引

        所以，我们在建立联合索引的时候，一定要把最常用的列放到最左边。索引的最左侧列不能丢失（可以理解为带头大哥或者火车头）。

4.2.1 如何创建联合索引

        有一天我们的 DBA 找到我，说我们的项目里面有两个查询很慢，按照我们的想法，一个查询创建一个索引，所以我们针对两条 SQL 创建了两个索引，这种做法觉得正确吗？

CREATE INDEX idx name on user_innodb(name);
CREATE INDEX idx_name_phone on user_innodb(name,phone);

当我们创建一个联合索引的时候，按照最左匹配原则，用左边的字段name去査询的时候，也能用到索引，所以第一个索引完全没必要。

相当于建立了两个联合索引(name),(name,phone)。
如果我们创建三个字段的索引index(a,b,c),相当于创建三个索引：
        index(a)
        index(a,b)
        index(a/b/c)
用where b=？和 where b=? and c=？是不能使用到索引的。

4.3 覆盖索引

        回表：非主键索引，我们先通过索引找到主键索引的键值，再通过主键值查出索引里面没有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程就叫回表。

        比如下图的查询就是一个回表操作。

        在二级索引里面，不管是单列索引还是联合索引，如果 select 的数据列只用从索引中就能够取得，不必从数据区中读取，这时候使用的索引就叫做覆盖索引，这样就避免了回表。

select * ，不是覆盖索引。因为覆盖索引减少了 IO 次数，减少了数据的访问量，可以大大地提升查询效率。

4.4 索引条件下推（ICP）

        索引条件下推(Index Condition Pushdown) , 5.6以后完善的功能。只适用于二级索引。ICP的目标是减少访问表的完整行的读数量从而减少I/O操作。这里说的下推，其实是意思是把过滤的动作在存储引擎做完，而不需要到Server层过滤。

        再来看这么一张表，在last_name和first_name上面创建联合索引。

alter table employees add index idx_lastname_firstname(last_name,first_name);

现在我们要査询所有姓wang,并且名字最后一个字是zi的员工，比如王胖子，王瘦子。查询的SQL：

select * from employees where last_name = 'wang' and first_name LIKE '%zi';

正常情况来说，因为字符是从左往右排序的，当你把％加在前面的时候，是不能基于索引去比较的，所以只有last_name （姓）这个字段能够用于索引比较和过滤。所以查询过程是这样的：

        1）根据联合索引查出所有姓 wang 的二级索引数据（三个主键值 6、7、8）；

        2）回表，到主键索引上查询全部符合条件的数据（3 条数据）；

        3）把这三条数据返回给 Server 层，在 Server 层过滤出名字以 zi 结尾的员工。

 注意，索引的比较是在存储引擎进行的，数据记录的比较，是在Server层进行的。 而当first_name的条件不能用于索引过滤时，Server层不会把first_name的条件传递给存储引擎，所以读取了两条没有必要的记录。这时候，如果满足last_name='wang'的记录有10万条，就会有99999条没有必要读取的记录。
所以，根据first_name字段过滤的动作，能不能在存储引擎层完成呢？

        这是第二种 查询方法：

        1）根据联合索引查出所有姓wang的二级索引数据（3个主键值：6、7、8）
        2）然后从二级索引中筛选出first_name以zi结尾的索引（1个索引）
        3）然后再回表，到主键索引上查询全部符合条件的数据（1条数据），返回给Server 层。

 很明显，第二种方式到主键索引上查询的数据更少。

  ICP是默认开启的，也就是说针对于二级索引，只要能够把条件下推给存储引擎，它就会下推，不需要我们干预:

-- 开启索引下推
set optimizer_switch = 'index_condition_pushdown=on';

-- 关闭索引下推
set optimizer_switch = 'index_condition_pushdown=off';

        查看参数：

show variables like 'optimizer_switch';

        执行一下 SQL，Using where：

explain select * from user where last_name = 'wang' and first_name like '%zi';

Using where 代表从存储引擎取回的数据不全部满足条件，需要在 Server 层过滤。先用last_name条件进行索引范围扫描，读取数据表记录，然后进行比较，检查是否符合first_name LIKE '%zi'的条件。此时3条中只有1条符合条件。

5. 索引的创建与使用

        因为索引对于改善查询性能的作用是巨大的，所以我们的目标是尽量使用索引。

5.1 索引的创建

1.  在用于 where 判断、order 排序、join 的 on、group by的字段上创建索引；
2. 索引的个数不要过多（浪费空间，更新变慢）；
3. 过长的字段，建立前缀索引，例如：

   CREATE TABLE 'pre_test' (
   'content' varchar(20) DEFAULT NULL,
   KEY 'pre idx' ('content' (6))
   )ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

4.  区分度低的字段，例如性别，不要建索引（离散度太低，导致扫描行数过多）；

5. 频繁更新的值，不要作为主键或者索引（页分裂）;

6. 随机无序的值，不建议作为索引，例如身份证、UUID（无序、分裂）；

7. 组合索引把散列性高(区分度高)的值放在前面；

8. 创建复合索引，而不是修改单列索引；

5.2 什么时候用不到索引？

        1、索引列上使用函数(replace\SUBSTR\CONCAT\sum count avg)、表达式、计算(+ - * /) :

explain SELECT * FROM 't2' where id+1 = 4;

        2、字符串不加引号，出现隐式转换；

        3、like条件中前面带％；
              where条件中like abc%, like %2673%, like %888都用不到索引吗？为什么?

        4、负向查询

                NOT LIKE 不能:

explain select *from user where last_name not like ‘wang’;

        !=(<>) 和 not in 在某些情况下可以使用到索引：

explain select *fiom user where user_no not in (1);
explain select *fiom user where user_no <> 1;

在这个例子中，因为索引是有序的，只要从1之后开始顺序读取就行了。

        注意跟数据库版本、数据量、数据选择度都有关系。其实，用不用索引，最终都是优化器说了算。

        优化器是基于什么的优化器？

        基于 cost 开销(Cost Base Optimizer),它不是基于规则(Rule-Based Optimizer), 也不是基于语义。怎么样开销小就怎么来。

        使用索引有基本原则，但是没有具体细则，没有什么情况一定用索引，什么情况一 定不用索引的规则。

                ​​​​​​​        ​​​​​​​        ​​​​​​​

         在我们的日常开发中，一定要正确使用索引，使我们的 SQL 达到最佳运行效率！