《MySQL》系列-小胖要的 MySQL 索引详解（附 20 张图解）

以你之姓@ 2022-11-10 10:38 190阅读 0赞

mysql 作为一个关系型数据库，在国内使用应该是最广泛的。也许你司使用 Oracle、Pg 等等，但是大多数互联网公司，比如我司使用得最多的还是 Mysql，重要性不言而喻。

事情是这样的，上一篇关于 MySQL 基础架构的文章发出以后，有小伙伴说能不能聊聊索引？日常工作中，我们遇到 sql 执行慢的时候，经常会收到这样的建议：“加个索引呗”。索引究竟是啥呢？它为啥能提高执行效率呢？这篇我们来聊聊~

# 01 索引是什么？ #

**索引是一种数据结构，它的出现就是为了提高数据查询的效率，就像一本书的目录**。想想一本书几百页，没有目录估计找得够呛的。举个通俗点的例子，我在知乎刷到的，比喻得很妙。

> 我们从小就用的新华字典，里面的声母查询方式就是聚簇索引。 偏旁部首就是二级索引 偏旁部首 + 笔画就是联合索引。

索引本身也是占用磁盘空间的（想想一本书中的目录也是占用页数的，你就知道了），它主要**以文件的形式存在于磁盘中**。

## 1.1 索引的优缺点 ##

**优点**

*  提高查询语句的执行效率，减少 IO 操作的次数
 *  创建唯一性索引，可以保证数据库表中每一行数据的唯一性
 *  加了索引的列会进行排序（一本书的章节顺序不就是按照目录来排嘛），在使用分组和排序子句进行查询时，可以显著减少查询中分组和排序的时间

**缺点**

*  索引需要占物理空间
 *  创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加
 *  当对表中的数据进行增删改查是，索引也要动态的维护，这样就降低了数据的更新效率

## 1.2 索引的分类 ##

**主键索引**

一种特殊的唯一索引，不允许有空值。(主键约束 = 唯一索引 + 非空值)

**唯一索引**

索引列中的值必须是唯一的，但是允许为空值。

**普通索引**

MySQL 中的加索引类型，没啥限制。**允许空值和重复值，纯粹为了提高查询效率而存在**。

**单列索引**

没啥好说的，就是索引的列数量只有一个，每个表可以有多个单列索引。

**组合索引**

多列值组成一个索引，专门用于组合搜索，其效率大于索引合并。注意，使用它的时候需要遵守**最左匹配原则**。多个列作为查询条件时，组合索引在工作中很常用。

**全文索引**

只能在文本内容，也就是 TEXT、CHAR、VARCHAR 数据类型的列上建全文索引。有人说创建单列索引不就完了吗？考虑一种情况：当这列的内容很长时，用 like 查询就会很慢，这是就适合建全文索引。

**前缀索引**

还是只能作用于文本内容，也就是 TEXT、CHAR、VARCHAR 数据类型的列上建前缀索引，它可以指定索引列的长度，它是这样写的：

// 在 x_test 的 x_name 列上创建一个长度为 4 的前缀索引
    alter table x_test add index(x_name(4));

这个长度是根据实际情况来定的。长了太占用空间，短了不起效果。比如：我有个表的 x\_name 的第一个字符几乎都是一样的（假设都是1），如果创建索引的长度 = 1，执行以下查询的时候就可能比原来更糟。**因为数据库里面太多第一个字符 = 1 的列了，所以选的时候尽量选择数据开始有差别的长度**。

SELECT * FROM x_test WHERE x_name = '1892008.205824857823401.800099203178258.8904820949682635656.62526521254';

**空间索引**

MySQL 在 5.7 之后的版本支持了空间索引，而且支持 OpenGIS 几何数据模型。MySQL 在空间索引这方面遵循 OpenGIS 几何数据模型规则。

# 02 索引的内存模型 #

**实现索引的方式有很多种，这里先介绍下最常见的三种：哈希表、有序数组、二叉树，其中二叉树又分为二叉查找树、平衡二叉树、B 树以及 B+ 树，从而说明为啥 InnDB 选择了 B+ 树**？为了方便作图举例我先建个表，建表语句如下：user 有两列，一列是身份证号，还有一列是名称。

CREATE TABLE IF NOT EXISTS `user`(
       `id_card` INT(6) NOT NULL,
       `name` VARCHAR(100) NOT NULL,
       PRIMARY KEY ( `id_card` )
    )ENGINE=InnoDB DEFAULT CHARSET=utf8;

## 2.1 哈希表 ##

HashMap 相信大家都用过，哈希表就是一种以键值对存储数据的结构。在 MySQL 中 key 用于存储索引列，value 就是某行的数据或者是它的磁盘地址。

用过 HashMap 的你可能知道了，当多个 key 经过哈希函数换算之后会出现同一个值，这种情况下就会 value 值的结构就是个链表。假设现在让你通过身份证号找名字，这时它的哈希表索引结构是这样的：

![哈希表索引][e1241144f00a510c5db0b69d69ae787d.png]

从上图可知，user2 和 user4 哈希出来的 key 值都是 M，这个时候 value 的值就是个链表。如果你要查 id\_card = 66688 的人，步骤是：先将 66688 通过哈希函数算出 M，然后按顺序遍历链表，找到 user2。

你可能注意到了上图中四个 id\_card 的值并不是递增的，所以增加新 user 时速度会很快，往后追加就好。但又因为不是有序的，做区间查询的速度就会很慢。

所以，**哈希表结构适用于只有等值查询的场景，不适合范围查询**。

## 2.2 有序数组 ##

为了解决区间查询速度慢的问题，有序数组应运而生。它的等值和范围查询都很快。还是上面根据身份号找用户的例子，这时候的索引结构是这样的：

![有序数组索引][3fa34fb9f7e8808da796f3ed01166496.png]

身份证号递增且不重复从而有以上有序数组，这是如果你要查 id\_card = 66666 的用户，用二分法就可以啦，复杂度是 O(log(N))。

这数组还支持范围查询，还是用二分查找法，如果你要查区间 \[12345,66666\]的用户，只需要二分查找出 id\_card 大于等于 12345 且小于 66666 的用户即可。

单看查询效率，有序数组简直完美，但是如果我们要新增数据就很很难受了。假设你要新增 id\_card = 12346 的用户，那就只能把后面的数据都往后挪一个位置，成本太高了。

所以**有序数组只适用于存储一些不怎么变的数据，比如一些过去的年份数据**。

## 2.3 二叉搜索树 ##

二叉搜索树，也称二叉查找树，或二叉排序树。其定义也比较简单，要么是一颗空树，要么就是具有如下性质的二叉树：**每个节点只有两个分叉，左子树所有节点值比右子树小，每个节点的左、右子树也是一个小的二叉树，且没有健值相等的节点**。

说概览有点懵，先上个图。一般的二叉搜索树长这样：

![一般的二叉搜索树][2db41eac5fa389f6a919e2b1dbe2cc6a.png]

之所以设计成二叉有序的结构是因为可以利用二分查找法，它的插入和查找的时间复杂度都是 O(log(N))，但是最坏情况下，它的时间复杂度是 O(n)，原因是在插入和删除的时候树没有保持平衡。比如顺拐的二叉树：

![顺拐的二叉搜索树][48ebd34fa8eea6ae416c2d56baae1b38.png]

所以**这种情况下，树的查询时间复杂度都变高，而且也不稳定**。

## 2.4 平衡二叉树 ##

平衡二叉树也叫 AVL 树，它与二叉查找树的区别在于**平衡**，它任意的左右子树之间的高度差不大于 1\*\*。我做了个对比，如下图：

![平衡二叉树与二叉查找树对比][f75220b515fabe6e5914e038a4703abe.png]

这样就很开心了，根据平衡二叉树的特点。它的查询时间复杂度是 O(log(N))，当然为了维护平衡它更新的时间复杂度也是 O(log(N))。貌似完美？但是还有问题。

学过数据结构都知道，时间复杂度与树高相关。你想想假设现在有一颗 100 万节点的平衡二叉树，树高 20。一次查询需要访问 20 个数据块。而根据计算机组成原理得知，从磁盘读一个数据快平均需要 10ms 的寻址时间。**PS：索引不止存在内存中，还会写到磁盘上，所以优化的核心在于减少磁盘的 IO 次数**。

也就是说，对于一个 100 万行的表，如果使用平衡二叉树来存储，单独访问一行可能需要 20 个 10ms 的时间，也就是 0.2s，这很难受了。

此外，平衡二叉树不支持快速的范围查询，范围查询时需要从根节点多次遍历，查询效率真心不高。

所以，**大多数的数据库存储也并不使用平衡二叉树**。

## 2.5 B 树 ##

上面分析我们知道了，查询慢是因为树高，要多次访问磁盘。为了让一个查询尽量少触及磁盘。我们可以降低树的高度，既然有二叉。那我们多分几个叉，树的高度不就降低了？所以，这时就用到了 B 树（你心里没点吗？哈哈哈）。

> 在 MySQL 的 InnoDB 存储引擎一次 IO 会读取的一页（默认一页 16K）的数据量，而二叉树一次 IO 有效数据量只有 16 字节，空间利用率极低。为了最大化利用一次 IO 空间，一个简单的想法是在每个节点存储多个元素，在每个节点尽可能多的存储数据。每个节点可以存储 1000 个索引（16k/16=1000），这样就将二叉树改造成了多叉树，通过增加树的叉树，将树从高瘦变为矮胖。构建 1 百万条数据，树的高度只需要 2 层就可以（1000\*1000=1 百万），也就是说只需要 2 次磁盘 IO 就可以查询到数据。磁盘 IO 次数变少了，查询数据的效率也就提高了。

B 树也叫 B- 树，一颗 m 阶（m 表示这棵树最多有多少个分叉）的 B 树。特点是：

*  每个非叶子节点并且非根节点最少有 m/2 个（向上取整），即内部节点的子节点个数最少也有 m/2 个。
 *  根节点至少有两个子节点，每个内节点（非叶子节点就是内节点）最多有 m 个分叉。
 *  B 树的所有节点都存储数据，一个节点包含多个元素，比如健值和数据，节点中的健值从小到大排序。
 *  叶子节点都在同一层，高度一致并且它们之间没有指针相连。

3 阶的 B 树结构如下图所示：

![B树索引][B]

*  等值查询

在这样的结构下我们找值等于 48 的数据，还是使用二分查找法。它的查询路径是这样的：数据库1->数据块3->数据块9。一共经过三次磁盘 IO，而同样数据量情况下，用平衡二叉树存储的树高肯定是更高的。它的 IO 次数显然是更高的。所以说 B 树其实是加快了查询效率。

*  范围查询

不知道大家注意到没有？ B 树的叶子节点，并没有指针相连。意味着如果是范围查询，比如我查 41~ 58 的数据。

首先，二分查找法访问：数据块1->数据块3->数据块9，找到 41；然后再回去从根节点遍历：数据块1->数据块3->数据块10，找到 58，一共经历了 6 次 IO 查询才算是完成，这样查询的效率就慢了很多。

它还存在以下问题：

> 1.叶子节点无指针相连，所以范围查询增加了磁盘 IO 次数，降低了查询效率。

> 2.如果 data 存储的是行记录，行的大小随着列数的增多，所占空间会变大。这时，一个页中可存储的数据量就会变少，树相应就会变高，磁盘 IO 次数就会变大。

所以说，**B 树还有优化的空间**。

## 2.6 B+ 树 ##

B+ 树其实是从 B 树衍生过来的。它与 B 树有两个区别：

*  B+ 树的非叶子节点不存放数据，只存放健值。
 *  B + 树的叶子节点之间存在双向指针相连，而且是双向有序链表

它的数据结构如下图所示：

![B+树索引][B 1]

由上图得知，B+ 树的数据都存放在叶子节点上。所以每次查询我们都需要检索到叶子节点才能把数据查出来。有人说了，那这不变慢了吗？B 树不一定要检索到叶子节点呀。

其实不然，因为 B+ 的非叶子节点不再存储数据。所以它可以存更多的索引，也即理论上 B+ 树的树高会比 B 树更低。从这个角度来说，与其为了非叶子结点上能存储值而选择 B 树，倒不如选择 B+ 树，降低树高。

我们通过分析来看看 B+ 树靠不靠谱。

*  **等值查询**

在这样的结构下我们找值等于 48 的数据，还是使用二分查找法。它的查询路径是这样的：数据块1->数据块3->数据块9。一共经过三次磁盘 IO，这没毛病。

*  **范围查询**

比如我查 41~ 49 的数据。首先二分查找访问：数据库1->数据块3->数据块8。一样经过了三次磁盘 IO，找到 41 缓存到结果集。

但由于叶子节点是个双向有序链表，这个时候只需要往后走。将 49 所在的数据块 9 加载到内存遍历，找到 49，查询结束，只走了 4 次磁盘 IO。

这里可以看出对于范围查询来说，相比于 B 树要走一遍老路，B+ 树就显得高效很多。

所以，**B+ 树中等值和范围查询都支持快速查。这样 MySQL 就选择了 B+ 树作为索引的内存模型**。

# 03 MySQL 的索引是如何执行的？ #

好了，可以作为所索引内存模型的数据结构都分析了一遍。最终 MySQL 还是选择了 B+ 树作为索引内存模型。那 B+ 树在具体的引擎中是怎么发挥作用的呢？一起来看看

## 3.1 InnDB 索引 ##

首先是 InnDB 索引，篇幅原因，我就聊聊主键索引和普通索引。

### 3.1.1 主键索引 ###

主键索引又叫聚簇索引，它使用 B+ 树构建，叶子节点存储的是数据表的某一行数据。当表没有创建主键索引是，InnDB 会自动创建一个 ROWID 字段用于构建聚簇索引。规则如下：

> 1.  在表上定义主键 PRIMARY KEY，InnoDB 将主键索引用作聚簇索引。
> 2.  如果表没有定义主键，InnoDB 会选择第一个不为 NULL 的唯一索引列用作聚簇索引。
> 3.  如果以上两个都没有，InnoDB 会使用一个 6 字节长整型的隐式字段 ROWID 字段构建聚簇索引。该 ROWID 字段会在插入新行时自动递增。

多说无益，以下面的 Student 表为例，它的 id 是主键，age 列为普通索引。

CREATE TABLE `student`  (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
      `age` int(11) NULL DEFAULT NULL,
      PRIMARY KEY (`id`) USING BTREE,
      INDEX `index_age`(`age`) USING BTREE
    ) ENGINE = InnoDB AUTO_INCREMENT = 66 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

表数据如下：

![表数据][1084a7eff6f00b4aa6398f44ce4e131f.png]

![主键索引结构图][7507944d68008518045610c3997e4e6e.png]

*  **主键索引等值查询 sql**：

select * from student where id = 38;

过程如下：

*  第一次磁盘 IO：从根节点检索，将数据块 1 加载到内存，比较 38 < 44，走左边。
 *  第二次磁盘 IO：将左边数据块 2 加载到内存，比较 8<37<38，走右边。
 *  第三次磁盘 IO：将右边数据块 6 加载到内存，比较 37<38，38=38。查询完毕，将数据返回客户端。

流程图：**3 次磁盘 IO**

![流程图][f5d5b81b8c9f2a60a6e16bf1c4c76d83.png]

*  **主键索引范围查询 sql**

select * from student where id between 38 and 44;

前面也介绍说了，B+ 树因为叶子节点有双向指针，范围查询可以直接利用双向有序链表。

过程如下：

*  第一次磁盘 IO：从根节点检索，将数据块 1 加载到内存，比较 38 < 44，走左边。
 *  第二次磁盘 IO：将左边数据块 2 加载到内存，比较 8<37<38，走右边。
 *  第三次磁盘 IO：将右边数据块 6 加载到内存，比较 37<38，38=38。走右边。
 *  第四次磁盘 IO：将右边数据块 7 加载到内存，比较 38<44=44。查询完毕，将数据返回客户端。

流程图：**一共四次磁盘IO**

![流程图][04cadb7acc54913388952af8e011ebdd.png]

### 3.1.2 普通索引 ###

*  **普通索引等值查询 sql**

在 InnDB 中，B+ 树普通索引不存储数据，只存储数据的主键值。比如本表中的 age，它的索引结构就是这样的：

![普通索引][c201963fe38a3004386aecc8b2847adf.png]

执行以下查询语句，它的流程又是怎样的呢？

select * from student where age = 48;

使用普通索引需要检索两次索引。第一次检索普通索引找出 age = 48 得到主键值，再使用主键到主键索引中检索获得数据。这个过程称为回表。

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

过程如下：

*  第一次磁盘 IO：从根节点检索，将数据块1 加载到内存，比较 48 < 54，走左边。
 *  第二次磁盘 IO：将左边数据块 2 加载到内存，比较 28<47<48，走右边。
 *  第三次磁盘 IO：将右边数据块 6 加载到内存，比较 47<48，48=48。得到主键 38。
 *  第四次磁盘 IO：从根节点检索，将根节点加载到内存，比较 38 < 44，走左边。
 *  第五次磁盘 IO：将左边数据块 2 加载到内存，比较 8<37<38，走右边。
 *  第六次磁盘 IO：将右边数据块 6 加载到内存，比较 37<38，38=38。查询完毕，将数据返回客户端。

流程图：**一共 6 次磁盘 IO**。

![流程图][a450de88d6daed3f2b64dd904d6d328a.png]

### 3.1.3 组合索引 ###

如果为每一种查询都设计一个索引，索引是不是太多了？如果我现在要根据学生的姓名去查它的年龄。假设这个需求出现的概览很低，但我们也不能让它走全表扫描吧？

但是为一个不频繁的需求创建一个（姓名）索引是不是有点浪费了？那该咋做呢？我们可以建个（name，age）的联合索引来解决呀。组合索引的结构如下图所示：

![组合索引结构][bc1b4cf3e567284077aa41df7d85fb6e.png]

执行以下查询语句，它的流程又是怎样的呢？

select * from student where name = '二狗5' and age = 48;

过程如下：

*  第一次磁盘 IO：从根节点检索，将数据块1 加载到内存，比较 二狗5 < 二狗6，走左边。
 *  第二次磁盘 IO：将左边数据块 2 加载到内存，比较 二狗2<二狗4<二狗5，走右边。
 *  第三次磁盘 IO：将右边数据块 6 加载到内存，比较 二狗4<二狗5，二狗5=二狗5。得到主键 38。
 *  第四次磁盘 IO：从根节点检索，将根节点加载到内存，比较 38 < 44，走左边。
 *  第五次磁盘 IO：将左边数据块 2 加载到内存，比较 8<37<38，走右边。
 *  第六次磁盘 IO：将右边数据块 6 加载到内存，比较 37<38，38=38。查询完毕，将数据返回客户端。

流程图：**一共六次磁盘 IO**

![组合索引执行流程][fe675f40923992ba88bbd94d1a7c6ccb.png]

### 3.1.4 最左匹配原则 ###

最左前缀匹配原则和联合索引的**索引存储结构和检索方式**是有关系的。

在组合索引树中，最底层的叶子节点按照第一列 name 列从左到右递增排列，但是 age 列是无序的，age 列只有在 name 列值相等的情况下小范围内递增有序。

就像上面的查询，B+ 树会先比较 name 列来确定下一步应该搜索的方向，往左还是往右。如果 name 列相同再比较 age 列。但是如果查询条件没有 name 列，B + 树就不知道第一步应该从哪个节点查起，**这就是所谓的最左匹配原则**。

可以说创建的 idx\_name\_age (name,age) 索引，相当于创建了 (name)、（name,age）两个索引。、

组合索引的最左前缀匹配原则：使用组合索引查询时，mysql 会一直向右匹配直至遇到范围查询 (>、<、between、like) 就停止匹配。

### 3.1.5 覆盖索引 ###

覆盖索引是一种很常用的优化手段。因为在上面普通索引的例子中，由于查询结果所需要的数据只在主键索引上有，所以不得不回表。那么有没有可能经过索引优化，避免回表呢？比如改成这样子：

select age from student where age = 48;

在上面普通索引例子中，如果我只需要 age 字段，那是不是意味着我们查询到普通索引的叶子节点就可以直接返回了，而不需要回表。这种情况就是覆盖索引。

看下执行计划：

覆盖索引的情况：

![覆盖索引][d3d6ba89762c4d815d317edfff8ac9b3.png]

未覆盖索引的情况：

![未覆盖索引][e12ee7b0d6d8e1fb2ba427af134cf243.png]

## 3.2 myisam 索引 ##

还是上面那张 student 表，建表语句：

CREATE TABLE `student`  (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
      `age` int(11) NULL DEFAULT NULL,
      PRIMARY KEY (`id`) USING BTREE,
      INDEX `index_age`(`age`) USING BTREE
    ) ENGINE = MyISAM AUTO_INCREMENT = 66 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

### 3.2.1 主键索引 ###

与 InnDB 不同的是 myisam 的数据文件和索引文件是分开存储的。**它的叶子节点存的是健值，数据是索引所在行的磁盘地址**。它的结构如下：表 student 的索引文件存放在 student.MYI 中，数据文件存储在 student.MYD 中。

![myisam 主键索引结构][myisam]

*  **主键索引等值查询**

select * from student where id = 38;

它的具体执行流程如下：

流程图：**一共 4 次磁盘 IO**。

![myisam主键等值查询流程][myisam 1]

*  **主键索引范围查询**

select * from student where id between 38 and 44;

过程如下：

*  第一次磁盘 IO：从根节点检索，将数据块 1 加载到内存，比较 38 < 44，走左边。
 *  第二次磁盘 IO：将左边数据块 2 加载到内存，比较 8<37<38，走右边。
 *  第三次磁盘 IO：将右边数据块 6 加载到内存，比较 37<38，38=38。得到索引所在行的内存地址。
 *  第四次磁盘 IO：根据地址到数据文件 student.MYD 中获取主键 38 对应的行记录。
 *  第五次磁盘 IO：将右边数据块 7 加载到内存，比较 38<44=44。得到索引所在行的内存地址。
 *  第六次磁盘 IO：根据地址到数据文件 student.MYD 中获取主键 44 对应的行记录。

### 3.2.2 普通索引 ###

在 MyISAM 中，辅助索引和主键索引的结构是一样的，没有任何区别，叶子节点的数据存储的都是行记录的磁盘地址。**只是主键索引的键值是唯一的，而辅助索引的键值可以重复**。

查询数据时，由于辅助索引的键值不唯一，可能存在多个拥有相同的记录，所以即使是等值查询，也需要按照范围查询的方式在辅助索引树中检索数据。

## 3.3 索引的使用技巧 ##

### 3.3.1 避免回表 ###

上面说了，回表的原因是因为查询结果所需要的数据只在主键索引上有，所以不得不回表。回表必然会影响性能。那怎么避免呢？

**使用覆盖索引**，举个栗子：还是上面的 student ，它的一条 sql 在业务上很常用：

select id, name, age from student where name = '二狗2';

而 student 表的其他字段使用频率远低于它，在这种情况下，如果我们在建立 name 字段的索引的时候，并不是使用单一索引，而是使用联合索引（name，age）这样的话再执行这个查询语句就可以根据辅助索引查询到的结果获取当前语句的完整数据。

这样就有效避免了通过回表再获取 age 的数据。喏，**这就是一个典型的用覆盖索引的优化策略减少回表的情况**。

### 3.3.2 联合索引的使用 ###

联合索引，在建立索引的时候，尽量在多个单列索引上判断下是否可以使用联合索引。联合索引的使用不仅可以节省空间，还可以更容易的使用到索引覆盖。比如上面的 student 表，我就建了 (name,age) 和 age 索引。

联合索引的创建原则，在创建联合索引的时候因该把频繁使用的列、区分度高的列放在前面，频繁使用代表索引利用率高，区分度高代表筛选粒度大。

也可以在常需要作为查询返回的字段上增加到联合索引中，如果在联合索引上增加一个字段而使用到了覆盖索引，这种情况下应该使用联合索引。

联合索引的使用

*  考虑当前是否已经存在多个可以合并的单列索引，如果有，那么将当前多个单列索引创建为一个联合索引。
 *  当前索引存在频繁使用作为返回字段的列，这个时候就可以考虑当前列是否可以加入到当前已经存在索引上，使其查询语句可以使用到覆盖索引。

### 3.3.3 索引下推 ###

现在我的表数据是这样的：加了一个 sex 列。

![数据表][3c9768053b3a229959f9a3713917a721.png]

说到满足最左前缀原则的时候，最左前缀可以用于在索引中定位记录。这时，你可能要问，那些不符合最左前缀的部分，会怎么样呢？

我们还是以学生表的联合索引（name，age）为例。如果现在有一个需求：检索出表中“名字第一个字是二，而且年龄是 38 岁的所有男生”。那么，SQL语句是这么写的：

select * from student where name like '张%' and age=38 and sex='男';

根据前缀索引规则，所以这个语句在搜索索引树的时候，只能用"张"，找到三个满足条件的记录（图中红框数据）。当然，这还不错，总比全表扫描要好。

然后呢？当然是判断其他条件是否满足。

在MySQL5.6之前，只能从满足条件的记录 id=18 开始一个个回表。到主键索引上找出数据行，再对比字段

而MySQL 5.6引入的索引下推优化（index condition pushdown），**可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数**。

它的整个执行的流程图是这样的：

![索引下推][9fdd31093d487ac1e499d5d806f9357d.png]

InnoDB在（name，age）索引内部就判断了 age 是否等于 38，对于不等于 38 的记录，直接判断并跳过。在我们的这个例子中，只需要对 id=18 和 id=65 这两条记录回表取数据判断，就只需要回表 2 次，这就是所谓的索引下推。

### 送点书 ###

如果看到这里，喜欢这篇文章的话，请帮点个好看。微信搜索**一个优秀的废人**，关注后回复**电子书**送你 1000+ 本编程电子书 ，包括 C、C++、Java、Python、GO、Linux、Git、数据库、设计模式、前端、人工智能、面试相关、数据结构与算法以及计算机基础，详情看下图。回复 **1024**送你一套完整的 java 视频教程。

![资源][3323892cf40d77aaf278896c2e9ffb04.png]

**巨人的肩膀**

*  《高性能MySQL》
 *  zhuanlan.zhihu.com/p/142361798
 *  cnblogs.com/lianzhilei/p/11250589.html
 *  blog.csdn.net/qq\_35190492/article/details/109257302
 *  time.geekbang.org/column/article/69636
 *  cnblogs.com/happyflyingpig/p/7662881.html
 *  tech.meituan.com/2014/06/30/mysql-index.html

### 总结 ###

本文讲解了索引是什么？它的优缺点、分类；索引的 6 种内存模型；为什么使用 B+ 树？InnDB 和 MyIsam 引擎的主键索引、普通索引、组合索引、覆盖索引都是怎么起作用的？最左匹配原则是啥？最后还聊了下使用索引的小技巧。可以说，索引相关的知识点都在这了。看完这一篇还不懂的话，你来捶我呀！

好啦，以上就是狗哥关于索引的总结。感谢各技术社区大佬们的付出，如果说我看得更远，那是因为我站在你们的肩膀上。希望这篇文章对你有帮助，我们下篇文章见~

[e1241144f00a510c5db0b69d69ae787d.png]: /images/20221023/5cd5f5a7485c4c518ddd6b06128838a8.png
[3fa34fb9f7e8808da796f3ed01166496.png]: /images/20221023/4a7728c24a284ee4b79a675f94f8f7e5.png
[2db41eac5fa389f6a919e2b1dbe2cc6a.png]: /images/20221023/f86fdf19e3d2453abaedfe3dc06c24ac.png
[48ebd34fa8eea6ae416c2d56baae1b38.png]: /images/20221023/0ad53113f4254a8b952b399e7e0ab273.png
[f75220b515fabe6e5914e038a4703abe.png]: /images/20221023/47b06e794d0d47028a90b393579cdeba.png
[B]: /images/20221023/9d5eb78157da497890c105a0a1133e73.png
[B 1]: /images/20221023/7f8aaf47f66e4e7bb6b6df33800b4879.png
[1084a7eff6f00b4aa6398f44ce4e131f.png]: /images/20221023/2c88163131ed4f2cb1f45479b7756ba1.png
[7507944d68008518045610c3997e4e6e.png]: /images/20221023/e244c4d7f8ac47038388beafe0421d3b.png
[f5d5b81b8c9f2a60a6e16bf1c4c76d83.png]: /images/20221023/f93667594e4b4d30be00d0b5126847ae.png
[04cadb7acc54913388952af8e011ebdd.png]: /images/20221023/7a4ee53194904f908929911110aabdfe.png
[c201963fe38a3004386aecc8b2847adf.png]: /images/20221023/239244b79fd34aa696a7e58b1e2e8dcf.png
[a450de88d6daed3f2b64dd904d6d328a.png]: /images/20221023/a85ec3471fb24a70bcfb62da8ea8f4fe.png
[bc1b4cf3e567284077aa41df7d85fb6e.png]: /images/20221023/eac3e97e2e8e4e2381b4711bae24ae5b.png
[fe675f40923992ba88bbd94d1a7c6ccb.png]: /images/20221023/0c934dffa8e64121942dbb64283c693b.png
[d3d6ba89762c4d815d317edfff8ac9b3.png]: /images/20221023/d2da249fa71444dda1c36e5349360a64.png
[e12ee7b0d6d8e1fb2ba427af134cf243.png]: /images/20221023/102dce57b34f46849a3c5180cea19859.png
[myisam]: /images/20221023/8b69576072f1479bae7e7539a26737cb.png
[myisam 1]: /images/20221023/8110a7574309464d9349da06935e4070.png
[3c9768053b3a229959f9a3713917a721.png]: /images/20221023/b350ca35bb64412ba1f64da9dc27ac4c.png
[9fdd31093d487ac1e499d5d806f9357d.png]: /images/20221023/065cda03208c4a85a5dcf285a0bf3752.png
[3323892cf40d77aaf278896c2e9ffb04.png]: /images/20221023/ab330dfa10674dd99444a7b8b0b63a19.png