1W字文：什么是回表查询、索引覆盖、最左匹配原则？聚集索引、非聚集索引的区别？

文章很长，而且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录博客园版 为您奉上珍贵的学习资源：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你实现技术自由，完成职业升级，薪酬猛涨！加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领

免费赠送资源宝库： Java 必备百度网盘资源大合集价值>10000元加尼恩领取

聊聊：什么是索引

索引其实是一种数据结构，能够帮助我们快速的检索数据库中的数据。

聊聊：Mysql支持那些索引？

Mysql支持 B-tree、Hash、Full-text 等索引；

不同的存储引擎支持的索引类型也不一样：

InnoDB 支持事务，支持行级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；

MyISAM 不支持事务，支持表级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；

Memory 不支持事务，支持表级别锁定，支持 B-tree、Hash 等索引，不支持 Full-text 索引；

NDB 支持事务，支持行级别锁定，支持 Hash 索引，不支持 B-tree、Full-text 等索引；

Archive 不支持事务，支持表级别锁定，不支持 B-tree、Hash、Full-text 等索引；

注：本文以 PDF 持续更新，最新尼恩架构笔记、面试题的PDF文件，请从下面的链接获取：码云或者语雀

聊聊：Mysql InnoDB引擎支持那些索引？

Mysql支持 B-tree、Hash、Full-text 等索引；

InnoDB引擎的索引类型有 B+树索引和 Hash索引，默认的索引类型为B+树索引。

InnoDB 不支持 Hash 索引；

Hash索引

哈希索引是基于哈希表实现的，

Hash索引是将一列或者多列数据值, 进行 hash运算, 并将结果映射到数组的某个位置上.

当hash值冲突时, 会追加一个链表存储数据.

Hash索引整个结构与 Java中的 HashMap的结果是类似的.

当我们要给某张表某列增加索引时，存储引擎会对这列进行哈希计算得到哈希码，

将哈希码的值作为哈希表的key值，将指向数据行的指针作为哈希表的value值。

这样查找一个数据的时间复杂度就是O(1)，一般多用于精确查找。

所以在如"=", IN, "<=>" 等值查找场景效率是非常，

由于 Hash索引本身的特殊性, 也带来了很多限制和弊端.

比如：用一个哈希函数把 key 换算成一个确定的位置，然后把 value 放在数组的这个位置;

多个 key 值经过哈希函数的换算，会出现同一个值的情况：处理这种情况的一种方法是，拉出一个链表, 值得注意的是这个链表中的值并不是有序的。

所以，我们开发一般会选择Btree，因为Hash会存在如下一些缺点。

Hash索引的缺点主要如下：

1.Hash索引只适合等值比较查找, 如"=", IN, "<=>", 不适合范围查找和匹配查找, 如like, ">", "<", ">"等;

2.Hash索引适合区分度很高的列, 反之, 会造成hash值的大量冲突, 大量数据在一个无序链表中比较查询, 性能可想而知.

3.因为散列数组的长度是有限的, 所以Hash索引也只适合数据量不是很大的情况下使用.

4.Mysql 中的 Innodb引擎是不支持手动创建 Hash索引的, 只提供了内部优化使用的自适应哈希索引(Adaptive Hash Index).

5.Hash 索引无法被用来避免数据的排序操作。

Hash表和B+树

hash表通过key值经过hash算法，直接定位到数据存储地址，然后取出value值。

时间复杂度O（1），找数据和存数据就需要那么一下子，就给找到了

hash存储方式支持增、删、改以及随机读取操作，但不支持顺序扫描，对应的存储系统为key-value存储系统。

对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作O(n)快,

简单来说，

如果不需要有序的遍历数据，哈希表就是最佳选择
如果需要有序的遍历数据，B+树就是最佳选择

索引能提升与磁盘IO优化

另外，相对于cpu和内存操作，磁盘IO开销是非常大的，磁盘IO非常容易成为系统的性能瓶颈。如何减少磁盘IO，成为索引优化的一个重要方向。

而为什么索引能提升数据库查询效率呢？根本原因就在于，经过索引机制的不断优化，减少了查询过程中的IO次数。

那么它是如何做到的呢？

使用B+树。下面先简单了解一下B树和B+树。

从二叉树，到B树和B+树的演进

要说清楚B+树，首先从二叉树说起，一颗非常普通的树，非常容易退化为一张链表。

因为二叉树会产生退化现象，提出了平衡二叉树，

在平衡二叉树基础上，需要减少遍历高度，怎样让每一层放的节点多一些数据，来引申出m叉树，

m叉搜索树同样会有退化现象，引出m叉平衡树，也就是B树，

B树(平衡多路二叉树)

B就是Balance 平衡的第一个字母。

B树，又叫平衡多路查找树。一棵m阶的B~树 (m叉树)的特性如下：

树中每个结点至多有m个孩子；
除根结点和叶子结点外，其它每个结点至少有[m/2]个孩子；
若根结点不是叶子结点，则至少有2个孩子；
所有叶子结点都出现在同一层，叶子结点不包含任何关键字信息(可以看做是外部接点或查询失败的接点，实际上这些结点不存在，指向这些结点的指针都为null)；
每个非终端结点中包含有n个关键字信息： (n，A0，K1，A1，K2，A2，......，Kn，An)。

其中，

a) Ki (i=1...n)为关键字，且关键字按顺序排序Ki < K(i-1)。
b) Ai为指向子树根的接点，且指针A(i-1)指向子树种所有结点的关键字均小于Ki，但都大于K(i-1)。
c) 关键字的个数n必须满足： [m/2]-1 <= n <= m-1

B 树是一种多叉的 AVL 树。

B-Tree 减少了 AVL 数的高度，增加了每个节点的 KEY 数量。

B树的问题：每个节点既放了key也放了value，怎样使每个节点放尽可能多的key值，以减少遍历高度呢（访问磁盘次数），

具体如何优化呢？

可以将每个节点只放key值，将value值放在叶子结点，在叶子结点的value值增加指向相邻节点指针，这就是优化后的B+树。

实际应用中，每个节点的最小单元不是 KEY，而一般是按照块（BLOCK）来算。

比如磁盘文件系统 EXT4 每块 4KB；

数据库比如 PostgreSQL 是 8KB，MySQL InnoDB 是 16KB， MySQL NDB 是 32KB 等。

上图每个节点的基本单元是一个磁盘块（BLOCK，默认 4KB），根节点含有一个键值，其他节点含有 3 个键值，每个磁盘块包含对应的键值与数据。

比如下面的B树，现在要读取 KEY 为 31 的记录：

先找到根节点磁盘块（1），读入内存。（第一次 IO）；

关键字 31 大于区间（16，），根据指针 P2 找到磁盘块 3，读入内存（第二次 IO）；

31 大于区间（20，24，28），根据指针 P4 读取磁盘块 11（第三次 IO），在磁盘块 11 中找到 KEY 为 31 的记录，返回结果。

实际应用中，每个节点的最小单元不是 KEY，而一般是按照块（BLOCK）来算。

三次 IO，前两次 IO 其实从磁盘读取了不必要的数据，因为只用比较 KEY，所以非叶子节点对应的 DATA 完全没有必要，如果 DATA 很大，那完全是浪费内存资源。

考虑下能否把非叶子节点的 DATA 拿掉？

B+树

B+Tree是在B-Tree基础上的一种优化，使其更适合实现外存储索引结构，

InnoDB存储引擎就是用B+Tree实现其索引结构。

从上一节中的B-Tree结构图中可以看到每个节点中不仅包含数据的key值，还有data值。

而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。

在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。

B+树：是应文件系统所需而产生的一种B树的变形树。

一棵m阶的B+树和m阶的B-树的差异在于：

有n棵子树的结点中含有n个关键字； (B~树是n棵子树有n+1个关键字)
所有的叶子结点中包含了全部关键字的信息，及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接。 (B~树的叶子节点并没有包括全部需要查找的信息)
所有的非终端结点可以看成是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。 (B~树的非终节点也包含需要查找的有效信息)

B+Tree相对于B-Tree有几点不同：

非叶子节点只存储键值。
所有叶子节点之间都有一个链指针。
数据记录都存放在叶子节点中。

将上一节中的B-Tree优化，由于B+Tree的非叶子节点只存储键值信息，假设每个磁盘块能存储4个键值及指针信息，则变成B+Tree后其结构如下图所示：

假设每个磁盘块能存储3个键值及指针信息，则变成B+Tree后其结构如下图所示：

上图一棵 B+ 树。

非叶子节点不再包含除了主键外的数据（卫星数据），数据全部放在叶子节点，并且所有叶子节点存放在一个单向链表里，当然也可以双向链表。

可以看到，B+ 树同时具有平衡多叉树和链表的优点，

即可兼顾 B 树对范围查找的高效，又可兼顾链表随机写入的高效，这也是大部分数据库都用 B+ 树来存储索引的原因。

B+Tree的根本优势

B+Tree的本质: 通过减少磁盘寻道次数来提高查询性能

通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。

因此可以对B+Tree进行两种查找运算：

一种是对于主键的范围查找和分页查找
另一种是从根节点开始，进行随机查找。

下面做一个推算：

InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为是估值，为方便计算，这里的K取值为10^3）。

也就是说一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿条记录。

实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在2~4层。

InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说:查找某一键值的行记录时最多只需要1~3次磁盘I/O操作。

聊聊: 为什么B+树比B树更适合实现数据库索引？

B+Tree相对于B-Tree有几点不同：

非叶子节点只存储键值信息。
所有叶子节点之间都有一个链指针。
数据记录都存放在叶子节点中。

为什么B+树比B树更适合实现数据库索引呢？原因有三：

B+ 树叶子结点之间用链表有序连接，所以扫描全部数据只需扫描一遍叶子结点，利于扫库和范围查询；

B 树由于非叶子结点也存数据，所以只能通过中序遍历按序来扫。

也就是说，对于范围查询和有序遍历而言，B+ 树的效率更高。

B+ 树更相比 B 树减少了 I/O 读写的次数。

由于索引文件很大因此索引文件存储在磁盘上，B+ 树的非叶子结点只存关键字不存数据，因而单个页可以存储更多的关键字，即一次性读入内存的需要查找的关键字也就越多，磁盘的随机 I/O 读取次数相对就减少了。

B+树的查询效率更加稳定，

任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

聊聊：索引的优缺点

优点

提高数据检索的效率，降低数据库IO成本。
通过索引对数据进行排序，降低数据的排序成本，降低CPU的消耗。

缺点

建立索引需要占用物理空间
会降低表的增删改的效率，因为每次对表记录进行增删改，需要进行动态维护索引，导致增删改时间变长

聊聊：什么情况下需要建索引？

主键自动创建唯一索引
较频繁的作为查询条件的字段
查询中排序的字段，查询中统计或者分组的字段

聊聊：什么情况下不建索引？

表记录太少的字段
经常增删改的字段
唯一性太差的字段，不适合单独创建索引。比如性别，民族，政治面貌

聊聊：索引主要有哪几种分类？

MySQL主要的几种索引类型：

普通索引
唯一索引
主键索引
组合索引
全文索引。

普通索引: 是最基本的索引，它没有任何限制
唯一索引: 索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一
主键索引: 是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。
组合索引: 一个索引包含多个列，实际开发中推荐使用组合索引。
全文索引(FULLTEXT ): 全文搜索的索引。FULLTEXT 用于搜索很长一篇文章的时候，效果最好。只能用于InnoDB或MyISAM表，只能为CHAR、VARCHAR、TEXT列创建。

主键索引和唯一索引的区别：

主键必唯一，但是唯一索引不一定是主键；

一张表上只能有一个主键，但是可以有一个或多个唯一索引。

聊聊：聚集索引、非聚集索引的区别？

聚集索引介绍

聚簇索引就是按照每张表的主键构造一颗B+树，同时叶子节点中存放的就是整张表的行记录数据，也将聚集索引的叶子节点称为数据页。这个特性决定了索引组织表中数据也是索引的一部分，每张表只能拥有一个聚簇索引。

如果表设置了主键，则主键就是聚簇索引
如果表没有主键，则会默认第一个NOT NULL，且唯一（UNIQUE）的列作为聚簇索引
以上都没有，则会默认创建一个隐藏的row_id作为聚簇索引

聚集索引的叶子节点就是整张表的行记录。InnoDB 主键使用的是聚簇索引。聚集索引要比非聚集索引查询效率高很多。

非聚集索引介绍

普通索引也叫二级索引，除聚簇索引外的索引，即非聚簇索引。

对于 InnoDB 而言，普通索引的叶子节点存储的是主键（聚簇索引）的值，

对于 MyISAM而言，普通索引的叶子节点存储的是记录指针。

示例

create table user(
    id int(10) auto_increment,
    name varchar(30),
    age tinyint(4),
    primary key (id),
    index idx_age (age)
    )engine=innodb charset=utf8mb4;

id 字段是聚簇索引，age 字段是普通索引（二级索引）

填充数据

insert into user(name,age) values('张三',30);
insert into user(name,age) values('李四',20);
insert into user(name,age) values('王五',40);
insert into user(name,age) values('赵六',10);
insert into user(name,age) values('田七',20);

mysql> select * from user;
+----+--------+------+
| id | name  | age |
+----+--------+------+
| 1 | 张三  |  30 |
| 2 | 李四  |  20 |
| 3 | 王五  |  40 |
| 4 | 赵六  |  10 |
| 5 | 田七  |  20 |
......

id 是主键，所以是聚簇索引，其叶子节点存储的是对应行记录的数据

聚簇索引查询

如果查询条件为主键（聚簇索引），则只需扫描一次B+树，即可通过聚簇索引定位到要查找的行记录数据。

如：select * from user where id = 3;

非聚簇索引存储结构

age 是普通索引（二级索引），非聚簇索引，

非聚簇索引，其叶子节点存储的是聚簇索引的的值

非聚簇索引查询

如果查询条件为普通索引（非聚簇索引），需要扫描两次B+树，

第一次扫描通过普通索引定位到聚簇索引的值，然后第二次扫描通过聚簇索引的值定位到要查找的行记录数据。

如：select * from user where age = 40;

先通过普通索引 age=40 定位到主键值 id=4
再通过聚集索引 id=3 定位到行记录数据(就是上面这一步)

聊聊：什么是回表查询？

先通过非聚簇索引定位到主键，再根据主键通过聚簇索引的定位行记录数据，就是回表查询。

先通过普通索引的值定位聚簇索引值，再通过聚簇索引的值定位行记录数据，需要扫描两次索引B+树，它的性能较扫一遍索引树更低。

InnoDB聚集索引的叶子节点存储行记录，因此， InnoDB必须要有，且只有一个聚集索引：

（1）如果表定义了主键，则PK就是聚集索引；

（2）如果表没有定义主键，则第一个非空唯一索引（not NULL unique）列是聚集索引；

（3）否则，InnoDB会创建一个隐藏的row-id作为聚集索引；

先创建一张表，sql 语句如下：

create table user(
    id int(10) auto_increment,
    name varchar(30),
    age tinyint(4),
    primary key (id),
    index idx_age (age)
    )engine=innodb charset=utf8mb4;

然后，我们再执行下面的 SQL 语句，插入几条测试数据。

insert into user(name,age) values('张三',30);
insert into user(name,age) values('李四',20);
insert into user(name,age) values('王五',40);
insert into user(name,age) values('赵六',10);
insert into user(name,age) values('田七',20);

mysql> select * from user;
+----+--------+------+
| id | name  | age |
+----+--------+------+
| 1 | 张三  |  30 |
| 2 | 李四  |  20 |
| 3 | 王五  |  40 |
| 4 | 赵六  |  10 |
| 5 | 田七  |  20 |
......

假设，现在我们要查询出 id 为 2 的数据。

那么执行 select * from user where ID = 2; 这条 SQL 语句就不需要回表。

原因是根据主键的查询方式，则只需要搜索 ID 这棵 B+ 树。

主键是唯一的，根据这个唯一的索引，MySQL 就能确定搜索的记录。

但当我们使用 age 这个索引来查询 age = 40 的记录时就要用到回表。

select * from user where age = 40 ;

原因是通过 age 这个普通索引查询方式，则需要先搜索 age 索引树，然后得到主键 ID 的值为 3，再到 ID 索引树搜索一次。

这个过程虽然用了索引，但实际上底层进行了两次索引查询，这个过程就称为回表。

也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。

这就是所谓的回表查询，先定位主键值，再定位行记录，它的性能较扫一遍索引树更低。

使用聚集索引（主键或第一个唯一索引）就不会回表，普通索引就会回表。

聊聊：什么是索引覆盖？

只需要在一棵索引树上就能获取SQL所需的所有列数据，无需回表，速度更快。

如果我们把上面的非聚簇索引查询的sql改下

select id,age from user where age = 30;

这个sql我们是不是就不用回表查询了，因为在非聚簇索引的叶子节点上已经有id和age的值。

所以根本不需要拿着id的值再去聚簇索引定位行记录数据了。

也就是在这一颗索引树上就可以完成对数据的检索，这样就实现了覆盖索引。

如果这个sql是

select id,age,name from user where age = 30;

那就不能实现索引覆盖了，因为name的值在age索引树上是没有的，还是需要拿着id的值再去聚簇索引定位行记录数据。

但是如果我们对age和name做一个组合索引idx_age_name(age,name),那就又可以实现索引覆盖了。

聊聊：如何实现索引覆盖？

常见的方法是：将被查询的字段，建立到联合索引里去。

例子

create table user (
id int primary key,
name varchar(20),
sex varchar(5),
index(name)
)engine=innodb;

注意，语句中通过 index(name) 创建了 name 索引

第一个sql：

select id,name from user where name='shenjian';

能够命中name索引，索引叶子节点存储了主键id，通过name的索引树即可获取id和name，

无需回表，符合索引覆盖，效率较高。

Extra：Using index。

第二个sql：

select id,name,sex from user where name='shenjian';

能够命中name索引，索引叶子节点存储了主键id，没有储存sex，sex字段必须回表查询才能获取到，

不符合索引覆盖，需要再次通过id值扫描聚集索引获取sex字段，效率会降低。

Extra：Using index condition。

如果把(name)单列索引升级为联合索引(name, sex)就不同了。

create table user1 (
id int primary key,
name varchar(20),
sex varchar(5),
index(name, sex)
)engine=innodb;

可以看到：

select id,name ... where name='shenjian';
select id,name,sex ... where name='shenjian';

单列索升级为联合索引(name, sex)后，索引叶子节点存储了主键id，name，sex，都能够命中索引覆盖，无需回表。

画外音，Extra：Using index。

聊聊：哪些场景可以利用索引覆盖来优化SQL？

场景1：全表count查询优化

原表为：
user(PK id, name, sex)；

直接：
select count(name) from user;

不能利用索引覆盖。

添加索引：
alter table user add key(name);

就能够利用索引覆盖提效。

场景2：列查询回表优化

这个例子不再赘述，将单列索引(name)升级为联合索引(name, sex)，即可避免回表。

场景3：分页查询

将单列索引(name)升级为联合索引(name, sex)，也可以避免回表。

聊聊：什么是最左匹配原则？

最左匹配原则就是指在联合索引中，如果你的 SQL 语句中用到了联合索引中的最左边的索引，那么这条 SQL 语句就可以利用这个联合索引去进行匹配。

例如某表现有索引(a,b,c)，现在你有如下语句：

select * from t where a=1 and b=1 and c =1;     #这样可以利用到定义的索引（a,b,c）,用上a,b,c

select * from t where a=1 and b=1;     #这样可以利用到定义的索引（a,b,c）,用上a,b

select * from t where b=1 and a=1;     #这样可以利用到定义的索引（a,b,c）,用上a,b，mysql有查询优化器）

select * from t where a=1;     #这样也可以利用到定义的索引（a,b,c）,用上a

select * from t where b=1 and c=1;     #这样不可以利用到定义的索引（a,b,c）

select * from t where a=1 and c=1;     #这样可以利用到定义的索引（a,b,c），但只用上a索引，b,c索引用不到

也就是说通过最左匹配原则你可以定义一个联合索引，但是使得多数查询条件都可以用到该索引。

值得注意的是，当遇到范围查询(>、<、between、like)就会停止匹配。也就是：

select * from t where a=1 and b>1 and c =1; #这样a,b可以用到（a,b,c），c用不到索引

这条语句只有 a,b 会用到索引，c 都不能用到索引。

这个原因可以从联合索引的结构来解释。

但是如果是建立(a,c,b)联合索引，则a,b,c都可以使用索引，因为优化器会自动改写为最优查询语句

select * from t where a=1 and b >1 and c=1;  #如果是建立(a,c,b)联合索引，则a,b,c都可以使用索引
#优化器改写为
select * from t where a=1 and c=1 and b >1;

这也是最左前缀原理的一部分，索引index1:(a,b,c)，只会走a, a,b, a,b,c 三类型的查询，

其实这里说的有一点问题，a,c也走，但是只走a字段索引，不会走c字段。

另外还有一个特殊情况说明下，

select * from table where a = '1' and b > ‘2’ and c='3'

这种类型的也只会有 a与b 走索引，c不会走。

select * from table where a = '1' and b > ‘2’ and c='3'

这种类型的sql语句，在a、b走完索引后，c肯定是无序了，所以c就没法走索引，

为啥呢？数据库会觉得还不如全表扫描c字段来的快。

以index （a,b,c）为例建立这样的索引相当于建立了索引a、ab、abc三个索引。

一个索引顶三个索引当然是好事，毕竟每多一个索引，都会增加写操作的开销和磁盘空间的开销。

聊聊：为什么要用最左匹配呢？

就是为了使用联合索引。

最左匹配原则都是针对联合索引来说的，那么为什么要使用联合索引呢？

一、为什么要使用联合索引？

1、减少开销。

建一个联合索引(col1,col2,col3)，实际相当于建了(col1)，(col1,col2)，(col1,col2,col3)三个索引。

每多一个索引，都会增加写操作的开销和磁盘空间的开销，所以，对于大量数据的表，使用联合索引会大大的减少开销！

2、覆盖索引。

对联合索引(col1,col2,col3)，

如果有如下的 SQL:

 select col1,col2,col3 from test where col1 =1 and col2=2

那么MySQL可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机io操作。

减少io操作，特别的随机io其实是dba主要的优化策略。

所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。

3、效率高。

索引列越多，通过索引筛选出的数据越少。

有1000W条数据的表，有如下SQL:

select from table where col1=1 and col2=2 and col3=3

假设假设每个条件可以筛选出10%的数据，

如果只有单值索引，那么通过该索引能筛选出1000W*10%=100w条数据，

然后再回表从100w条数据中找到符合col2=2 and col3=3的数据，然后再排序，再分页；

如果是联合索引，

通过索引筛选出1000w*10%*10%*10%=1w条数据，

效率提升可想而知！

二、最左前缀匹配原则

对于联合索引，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的顺序可以任意调整。

误区：
对于联合索引(a,b)，只有where a=1 and b=2可以使用到索引，而where b=2 and a=1无法使用索引。

实际上：where a=1 and b=2 等价于 where b=2 and a=1 ，

两个语句都可以使用到联合索引(a,b)。

这是因为MySQL的查询优化器会判断SQL语句以什么样的顺序执行效率最高，当然能尽量利用索引时查询效率最高，所以MySQL查询优化器会以最合理的顺序执行查询。

三、最左匹配原则的原理

我们都知道联合索引当然还是一颗B+树，只不过联合索引的健值数量不是一个，而是多个。

构建一颗 B+树只能根据一个值来构建，因此数据库依据联合索引最左的字段来构建B+树。

例子：假如创建一个(a,b,c)的联合索引，那么它的索引树是这样的：

该图就是一个形如(a,b,c)联合索引的b+树，其中:

非叶子节点存储的是第一个关键字的索引a，
而叶子节点存储的是三个关键字的数据。

总的原则：联合索引就是按照第一列进行排序，然后第一列排好序的基础上再对第二列进行排序，以此类推。

这里可以看出a是有序的，
在a不同的前提下，而b, c都是无序的。
但是当在a相同的时候，b是有序的，b相同的时候，c又是有序的。

通过对联合索引的结构的了解，那么就可以很好的了解为什么最左匹配原则中如果遇到范围查询就会停止了。

以select * from t where a=5 and b＞0 and c=1; 为例

这样a,b可以用到(a,b,c)，c不可以，

当查询到b的值以后，这b是一个范围值，在一个范围里边， c是无序的，

所以，就不能根据联合索引，来确定到底该取哪一行。

联合索引就是按照第一列进行排序，然后第一列排好序的基础上再对第二列进行排序，以此类推。

如果没有第一列直接访问第二列，第二列肯定是无序的，直接访问后面的列就用不到索引了。

聊聊：索引失效的主要场景有哪些？

理解了上面聚集索引相对于非聚集索引的树的结构，对于什么时候索引会失效，理解起来就不那么难了。

组合索引未使用最左前缀，
例如组合索引（age，name），
where name='张三’ 不会使用索引;
or 会使索引失效。
如果查询字段相同，也可以使用索引。
例如where age=20 or age=30（索引生效），
where age=20 or name=‘张三’（这里就算你age和name都单独建索引，还是一样失效）;
如果列类型是字符串，不使用引号。
例如 where name=张三(索引失效），
改成 where name=‘张三’(索引有效);
like未使用最左前缀，
where A like ‘%China’;
在索引列上做任何操作计算、函数，会导致索引失效而转向全表扫描;
如果mysql估计使用全表扫描要比使用索引快,则不使用索引;

实操学习：MySQL 索引失效的 15 种场景

无论你是技术大佬，还是刚入行的小白，时不时都会踩到Mysql数据库不走索引的坑。

常见的现象就是：明明在字段上添加了索引，但却并未生效。

前些天就遇到一个稍微特殊的场景，同一条SQL语句，在某些参数下生效，在某些参数下不生效，这是为什么呢？

为了方便学习和记忆，这篇文件将常见的15种不走索引情况进行汇总，并以实例展示，帮助大家更好地避免踩坑。

数据库及索引准备

创建表结构

为了逐项验证索引的使用情况，我们先准备一张表t_user：

CREATE TABLE `t_user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `id_no` varchar(18) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '身份编号',
  `username` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '用户名',
  `age` int(11) DEFAULT NULL COMMENT '年龄',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (`id`),
  KEY `union_idx` (`id_no`,`username`,`age`),
  KEY `create_time_idx` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

在上述表结构中有三个索引：

id：为数据库主键；
union_idx：为id_no、username、age构成的联合索引；
create_time_idx：是由create_time构成的普通索引；

初始化数据

初始化数据分两部分：基础数据和批量导入数据。

基础数据insert了4条数据，其中第4条数据的创建时间为未来的时间，用于后续特殊场景的验证：

INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1001', 'Tom1', 11, '2022-02-27 09:04:23');
INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1002', 'Tom2', 12, '2022-02-26 09:04:23');
INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1003', 'Tom3', 13, '2022-02-25 09:04:23');
INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1004', 'Tom4', 14, '2023-02-25 09:04:23');

除了基础数据，还有一条存储过程及其调用的SQL，方便批量插入数据，用来验证数据比较多的场景：

-- 删除历史存储过程
DROP PROCEDURE IF EXISTS `insert_t_user`
 
-- 创建存储过程
delimiter $
 
CREATE PROCEDURE insert_t_user(IN limit_num int)
BEGIN
 DECLARE i INT DEFAULT 10;
    DECLARE id_no varchar(18) ;
    DECLARE username varchar(32) ;
    DECLARE age TINYINT DEFAULT 1;
    WHILE i < limit_num DO
        SET id_no = CONCAT("NO", i);
        SET username = CONCAT("Tom",i);
        SET age = FLOOR(10 + RAND()*2);
        INSERT INTO `t_user` VALUES (NULL, id_no, username, age, NOW());
        SET i = i + 1;
    END WHILE;
 
END $
-- 调用存储过程
call insert_t_user(100);

关于存储过程的创建和存储，可暂时不执行，当用到时再执行。

数据库版本及执行计划

查看当前数据库的版本：

select version();
8.0.18

上述为本人测试的数据库版本：8.0.18。

当然，以下的所有示例，大家可在其他版本进行执行验证。

查看SQL语句执行计划，一般我们都采用explain关键字，通过执行结果来判断索引使用情况。

执行示例：

explain select * from t_user where id = 1;

执行结果：

explain

可以看到上述SQL语句使用了主键索引（PRIMARY），key_len为4；

其中key_len的含义为：表示索引使用的字节数，

根据这个值可以判断索引的使用情况，

特别是在组合索引的时候，判断该索引有多少部分被使用到，非常重要。

做好以上数据及知识的准备，下面就开始讲解具体索引失效的实例了。

1 联合索引不满足最左匹配原则

联合索引遵从最左匹配原则，顾名思义，在联合索引中，最左侧的字段优先匹配。

因此，在创建联合索引时，where子句中使用最频繁的字段放在组合索引的最左侧。

而在查询时，要想让查询条件走索引，则需满足：最左边的字段要出现在查询条件中。

实例中，union_idx联合索引组成：

KEY `union_idx` (`id_no`,`username`,`age`)

最左边的字段为id_no，一般情况下，只要保证id_no出现在查询条件中，则会走该联合索引。

示例一：

explain select * from t_user where id_no = '1002';

explain结果：

通过explain执行结果可以看出，上述SQL语句走了union_idx这条索引。

这里再普及一下key_len的计算：

id_no 类型为varchar(18)，字符集为utf8mb4_bin，也就是使用4个字节来表示一个完整的UTF-8。
此时，key_len = 18* 4 = 72；
由于该字段类型varchar为变长数据类型，需要再额外添加2个字节。
此时，key_len = 72 + 2 = 74；
由于该字段允许为NULL（default NULL），需要再添加1个字节。
此时，key_len = 74 + 1 = 75；

上面演示了key_len一种情况的计算过程，后续不再进行逐一推演，知道基本组成和原理即可，更多情况大家可自行查看。

示例二：

explain select * from t_user where id_no = '1002' and username = 'Tom2';

explain结果：

很显然，依旧走了union_idx索引，根据上面key_len的分析，

大胆猜测，在使用索引时，不仅使用了id_no列，还使用了username列。

示例三：

explain select * from t_user where id_no = '1002' and age = 12;

explain结果：

走了union_idx索引，但跟示例一一样，只用到了id_no列。

当然，还有三列都在查询条件中的情况，就不再举例了。

上面都是走索引的正向例子，也就是满足最左匹配原则的例子，下面来看看，不满足该原则的反向例子。

反向示例：

explain select * from t_user where username = 'Tom2' and age = 12;

explain结果：

explain-04

此时，可以看到未走任何索引，也就是说索引失效了。

同样的，下面只要没出现最左条件的组合，索引也是失效的：

explain select * from t_user where age = 12;
explain select * from t_user where username = 'Tom2';

那么，第一种索引失效的场景就是：在联合索引的场景下，查询条件不满足最左匹配原则。

2 使用了`select *`

在《阿里巴巴开发手册》的ORM映射章节中有一条【强制】的规范：

【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。说明:1)增加查询分析器解析成本。2)增减字段容易与 resultMap 配置不一致。3)无用字段增加网络消耗，尤其是 text 类型的字段。

虽然在规范手册中没有提到索引方面的问题，但禁止使用select * 语句可能会带来的附带好处就是：某些情况下可以走覆盖索引。

比如，在上面的联合索引中，如果查询条件是age或username，当使用了select * ，肯定是不会走索引的。

但如果希望根据username查询出id_no、username、age这三个结果（均为索引字段），明确查询结果字段，是可以走覆盖索引的：

explain select id_no, username, age from t_user where username = 'Tom2';explain select id_no, username, age from t_user where age = 12;

explain结果：

覆盖索引

无论查询条件是username还是age，都走了索引，根据key_len可以看出使用了索引的所有列。

第二种索引失效场景：在联合索引下，尽量使用明确的查询列来趋向于走覆盖索引；

这一条不走索引的情况属于优化项，如果业务场景满足，则进来促使SQL语句走索引。至于阿里巴巴开发手册中的规范，只不过是两者撞到一起了，规范本身并不是为这条索引规则而定的。

3 索引列参与运算

直接来看示例：

explain select * from t_user where id + 1 = 2 ;

explain结果：

索引列计算

可以看到，即便id列有索引，由于进行了计算处理，导致无法正常走索引。

针对这种情况，其实不单单是索引的问题，还会增加数据库的计算负担。就以上述SQL语句为例，数据库需要全表扫描出所有的id字段值，然后对其计算，计算之后再与参数值进行比较。如果每次执行都经历上述步骤，性能损耗可想而知。

建议的使用方式是：先在内存中进行计算好预期的值，或者在SQL语句条件的右侧进行参数值的计算。

针对上述示例的优化如下：

-- 内存计算，得知要查询的id为1
explain select * from t_user where id = 1 ;
-- 参数侧计算
explain select * from t_user where id = 2 - 1 ;

第三种索引失效情况：索引列参与了运算，会导致全表扫描，索引失效。

4 索引列参使用了函数

示例：

explain select * from t_user where SUBSTR(id_no,1,3) = '100';

explain结果：

索引-函数

上述示例中，索引列使用了函数（SUBSTR，字符串截取），导致索引失效。

此时，索引失效的原因与第三种情况一样，都是因为数据库要先进行全表扫描，获得数据之后再进行截取、计算，导致索引索引失效。同时，还伴随着性能问题。

示例中只列举了SUBSTR函数，像CONCAT等类似的函数，也都会出现类似的情况。解决方案可参考第三种场景，可考虑先通过内存计算或其他方式减少数据库来进行内容的处理。

第四种索引失效情况：索引列参与了函数处理，会导致全表扫描，索引失效。

5 错误的Like使用

示例：

explain select * from t_user where id_no like '%00%';

explain结果：

针对like的使用非常频繁，但使用不当往往会导致不走索引。

常见的like使用方式有：

方式一：like '%abc'；
方式二：like 'abc%'；
方式三：like '%abc%'；

其中方式一和方式三，由于占位符出现在首部，导致无法走索引。

这种情况不做索引的原因很容易理解，索引本身就相当于目录，从左到右逐个排序。

而条件的左侧使用了占位符，导致无法按照正常的目录进行匹配，导致索引失效就很正常了。

第五种索引失效情况：模糊查询时（like语句），模糊匹配的占位符位于条件的首部。

6 类型隐式转换

示例：

explain select * from t_user where id_no = 1002;

explain结果：

id_no字段类型为varchar，但在SQL语句中使用了int类型，导致全表扫描。

出现索引失效的原因是：varchar和int是两个种不同的类型。

解决方案就是将参数1002添加上单引号或双引号。

第六种索引失效情况：参数类型与字段类型不匹配，导致类型发生了隐式转换，索引失效。

这种情况还有一个特例，如果字段类型为int类型，而查询条件添加了单引号或双引号，则Mysql会参数转化为int类型，虽然使用了单引号或双引号：

explain select * from t_user where id = '2';

上述语句是依旧会走索引的。

7、使用OR操作

OR是日常使用最多的操作关键字了，但使用不当，也会导致索引失效。

示例：

explain select * from t_user where id = 2 or username = 'Tom2';

explain结果：

看到上述执行结果是否是很惊奇啊，明明id字段是有索引的，由于使用or关键字，索引竟然失效了。

其实，换一个角度来想，如果单独使用username字段作为条件很显然是全表扫描，既然已经进行了全表扫描了，前面id的条件再走一次索引反而是浪费了。所以，在使用or关键字时，切记两个条件都要添加索引，否则会导致索引失效。

但如果or两边同时使用“>”和“<”，则索引也会失效：

explain select * from t_user where id  > 1 or id  < 80;

explain结果：

第七种索引失效情况：查询条件使用or关键字，其中一个字段没有创建索引，则会导致整个查询语句索引失效；or两边为“>”和“<”范围查询时，索引失效。

8 两列做比较

如果两个列数据都有索引，但在查询条件中对两列数据进行了对比操作，则会导致索引失效。

这里举个不恰当的示例，比如age小于id这样的两列（真实场景可能是两列同维度的数据比较，这里迁就现有表结构）：

explain select * from t_user where id > age;

explain结果：

这里虽然id有索引，age也可以创建索引，但当两列做比较时，索引还是会失效的。

第八种索引失效情况：两列数据做比较，即便两列都创建了索引，索引也会失效。

9 不等于比较

示例：

explain select * from t_user where id_no <> '1002';

explain结果：

当查询条件为字符串时，使用”<>“或”!=“作为条件查询，有可能不走索引，但也不全是。

explain select * from t_user where create_time != '2022-02-27 09:56:42';

上述SQL中，由于“2022-02-27 09:56:42”是存储过程在同一秒生成的，大量数据是这个时间。执行之后会发现，当查询结果集占比比较小时，会走索引，占比比较大时不会走索引。此处与结果集与总体的占比有关。

需要注意的是：上述语句如果是id进行不等操作，则正常走索引。

explain select * from t_user where id != 2;

explain结果：

第九种索引失效情况：查询条件使用不等进行比较时，需要慎重，普通索引会查询结果集占比较大时索引会失效。

10 is not null

示例：

explain select * from t_user where id_no is not null;

explain结果：

第十种索引失效情况：查询条件使用is null时正常走索引，使用is not null时，不走索引。

11 not in和not exists

在日常中使用比较多的范围查询有in、exists、not in、not exists、between and等。

explain select * from t_user where id in (2,3);
explain select * from t_user where id_no in ('1001','1002'); 
explain select * from t_user u1 where exists (select 1 from t_user u2 where u2.id  = 2 and u2.id = u1.id); 
explain select * from t_user where id_no between '1002' and '1003';

上述四种语句执行时都会正常走索引，具体的explain结果就不再展示。主要看不走索引的情况：

explain select * from t_user where id_no not in('1002' , '1003');

explain结果：

当使用not in时，不走索引？把条件列换成主键试试：

explain select * from t_user where id not in (2,3);

explain结果：

如果是主键，则正常走索引。

第十一种索引失效情况：查询条件使用not in时，如果是主键则走索引，如果是普通索引，则索引失效。

再来看看not exists：

explain select * from t_user u1 where not exists (select 1 from t_user u2 where u2.id  = 2 and u2.id = u1.id);

explain结果：

当查询条件使用not exists时，不走索引。

第十二种索引失效情况：查询条件使用not exists时，索引失效。

12 order by导致索引失效

示例：

explain select * from t_user order by id_no ;

explain结果：

其实这种情况的索引失效很容易理解，毕竟需要对全表数据进行排序处理。

那么，添加删limit关键字是否就走索引了呢？

explain select * from t_user order by id_no limit 10;

explain结果：

结果依旧不走索引。在网络上看到有说如果order by条件满足最左匹配则会正常走索引，在当前8.0.18版本中并未出现。所以，在基于order by和limit进行使用时，要特别留意。是否走索引不仅涉及到数据库版本，还要看Mysql优化器是如何处理的。

这里还有一个特例，就是主键使用order by时，可以正常走索引。

explain select * from t_user order by id desc;

explain结果：

可以看出针对主键，还是order by可以正常走索引。

另外，笔者测试如下SQL语句：

explain select id from t_user order by age;explain select id , username from t_user order by age;
explain select id_no from t_user order by id_no;

上述三条SQL语句都是走索引的，也就是说覆盖索引的场景也是可以正常走索引的。

现在将id和id_no组合起来进行order by：

explain select * from t_user order by id,id_no desc;
explain select * from t_user order by id,id_no desc limit 10;explain select * from t_user order by id_no desc,username desc;

explain结果：

上述两个SQL语句，都未走索引。

第十三种索引失效情况：当查询条件涉及到order by、limit等条件时，是否走索引情况比较复杂，而且与Mysql版本有关，通常普通索引，如果未使用limit，则不会走索引。order by多个索引字段时，可能不会走索引。其他情况，建议在使用时进行expain验证。

13 参数不同导致索引失效

此时，如果你还未执行最开始创建的存储过程，建议你先执行一下存储过程，然后执行如下SQL：

explain select * from t_user where create_time > '2023-02-24 09:04:23';

其中，时间是未来的时间，确保能够查到数据。

explain结果：

可以看到，正常走索引。

随后，我们将查询条件的参数换个日期：

explain select * from t_user where create_time > '2022-02-27 09:04:23';

explain结果：

此时，进行了全表扫描。这也是最开始提到的奇怪的现象。

为什么同样的查询语句，只是查询的参数值不同，却会出现一个走索引，一个不走索引的情况呢？

答案很简单：上述索引失效是因为DBMS发现全表扫描比走索引效率更高，因此就放弃了走索引。

也就是说，当Mysql发现通过索引扫描的行记录数超过全表的10%-30%时，优化器可能会放弃走索引，自动变成全表扫描。某些场景下即便强制SQL语句走索引，也同样会失效。

类似的问题，在进行范围查询（比如>、< 、>=、<=、in等条件）时往往会出现上述情况，而上面提到的临界值根据场景不同也会有所不同。

第十四种索引失效情况：当查询条件为大于等于、in等范围查询时，根据查询结果占全表数据比例的不同，优化器有可能会放弃索引，进行全表扫描。

14 其他

当然，还有其他一些是否走索引的规则，这与索引的类型是B-tree索引还是位图索引也有关系，就不再详细展开。

这里要说的其他，可以总结为第十五种索引失效的情况：Mysql优化器的其他优化策略，比如优化器认为在某些情况下，全表扫描比走索引快，则它就会放弃索引。

针对这种情况，一般不用过多理会，当发现问题时再定点排查即可。

小结

本篇文章为大家总结了15个常见的索引失效的场景，由于不同的Mysql版本，索引失效策略也有所不同。

大多数索引失效情况都是明确的，有少部分索引失效会因Mysql的版本不同而有所不同。

因此，建议收藏本文，当在实践的过程中进行对照，如果没办法准确把握，则可直接执行explain进行验证。

聊聊：索引的设计原则

索引列的区分度越高，索引的效果越好。
比如使用性别这种区分度很低的列作为索引，效果就会很差。
尽量使用短索引，对于较长的字符串进行索引时，应该指定一个较短的前缀长度，因为较小的索引涉及到的磁盘I/O较少，查询速度更快。
索引不是越多越好，每个索引都需要额外的物理空间，维护也需要花费时间。
利用最左前缀原则。
长字符串创建索引时，最好是前缀索引

聊聊：如何给长字符串,创建如何更好的创建索引?

我们知道，MySQL中，数据和索引都是在一颗 B+树 上，我们建立索引的时候，这棵树所占用的空间越小，检索速度就会越快，而varchar格式的字符串有些会很长，那么在效率为上的今天，我们如何更加合理的建立字符串的索引呢？

假如说我们一张表中存在 email 字段，现在要给 email 字段创建索引，email 字段值的格式为：zhangsan@qq.com。

有2种建立索引的方式：

1、直接给 email 字段建立索引：

alter table t add index index1(email);

索引树结构为：

2、建立 email 的前缀索引：

alter table t add index index2(email(6));

索引数据结构为：

此时我们的查询语句为：

select id,name,email from t where email='zhangsh123@xxx.com';

当使用index1索引时其执行步骤为：

1、从index1索引树查找索引值为zhangsh123@xxx.com的主键值ID1；

2、根据ID1回表查到该行数据确实为zhangsh123@xxx.com，将结果加入结果集；

3、继续查找index1索引树下一个索引值是否满足zhangsh123@xxx.com，不满足则结束查询。

当使用index2索引时其执行步骤为：

1、从index2索引树查找索引值为zhangs的主键值ID1；

2、根据ID1回表查到该行数据确实为zhangsh123@xxx.com，将结果加入结果集；

3、继续查找index2索引树下一个索引值是否满足zhangs，满足则继续回表查询该行数据是否为zhangsh123@xxx.com，不是则跳过继续查找；

4、持续查找index2索引树，直到索引值不是zhangs为止。

从以上分析中我们可以看出，全字段索引相比前缀索引来说，减少了回表的次数，但是如果我们将前缀从6个增加到7个8个的话，前缀索引回表的次数就会减少，也就是说，只要定义好前缀的长度，我们就能既节省空间又保证效率。

那么问题来了，我们怎么衡量使用前缀索引的长度呢？

1、使用 select count(distinct email) as L from t; 查询字段不同值的个数；

2、依次选取不同的前缀长度查看不同值的个数：

select
    count(distinct left(email,4)）as L4,
    count(distinct left(email,5)）as L5,
    count(distinct left(email,6)）as L6,
    count(distinct left(email,7)）as L7,
from t;

然后根据实际可接受的损失比例，选取适合的最短的前缀长度。

前缀的长度问题我们解决了，但是一个问题是，如果使用前缀索引，那我们索引覆盖的特性就用不到了。

用全字段索引时，当我们查询select id,email from t where email='zhangsh123@xxx.com';时，不用回表直接就能查到id和email字段。

但是用前缀索引时，MySQL并不清楚前缀是否会整个覆盖email的值，无论是否全包含都会根据主键值回表查询判断。

所以说，使用前缀索引虽然能节省空间保证效率但是却不能用到覆盖索引的特性，是否使用就在于具体考虑了。