【极客时间】《MySQL45讲》学习笔记

一时失言乱红尘 2023-10-09 14:41 30阅读 0赞

**内容来源：**[开篇词 | 这一次，让我们一起来搞懂MySQL-极客时间][_ _MySQL-]

![d8ddde2b693443b591ab1b1f622e7ff8.png][]

**以下是来自网友对课程的知识点的分类总结：**

本章内容【本章内容建议阅读时长】

*  编号｜建议阅读时长｜文章标题

###  ###

## 1. 基础知识【12’】 ##

### 1.1 01 |12’| 基础架构：一条SQL查询语句是如何执行的？ ###

**内容来源：**[01 | 基础架构：一条SQL查询语句是如何执行的？-极客时间][01 _ _SQL_-]

看事情不要直接陷入细节里，应该先鸟瞰其全貌，从高维度理解问题。

使用数据库时，也应该把它看作一个整体。

以下是MySQL 的基本架构示意图，通过下图来理解SQL语句在MySQL的各个功能模块中的执行过程：

![7c9cb1fb3fd3461884bd464107da95d1.png][]

大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。

Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。

也就是说，你执行 create table 建表的时候，如果不指定引擎类型，默认使用的就是 InnoDB。不过，你也可以通过指定存储引擎的类型来选择别的引擎，比如在 create table 语句中使用 engine=memory, 来指定使用内存引擎创建表。不同存储引擎的表数据存取方式不同，支持的功能也不同，在后面的文章中，我们会讨论到引擎的选择。

从图中不难看出，不同的存储引擎共用一个 Server 层，也就是从连接器到执行器的部分。你可以先对每个组件的名字有个印象，接下来我会结合开头提到的那条 SQL 语句，带你走一遍整个执行流程，依次看下每个组件的作用。

#### 1.1.1 连接器 ####

**连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般是这么写的：**

mysql -h$ip -P$port -u$user -p

输完上述命令之后，就需要在交互对话中输入密码，直接在命令行-p后面输入密码会导致密码泄露，因此不推荐使用这种方式，尤其是连接生产服务器时。

连接命令中的 mysql 是客户端工具，用来跟服务端建立连接。在完成经典的 TCP 握手后，连接器就要开始认证你的身份，这个时候用的就是你输入的用户名和密码。

*  如果用户名或密码不对，你就会收到一个"Access denied for user"的错误，然后客户端程序结束执行。
 *  如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。

这就意味着，**一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。**

连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。文本中这个图是 show processlist 的结果，其中的 Command 列显示为“Sleep”的这一行，就表示现在系统里面有一个空闲连接。

![0524ecaec7464a1aaf4b6577bb39e086.png][]

**实测：**

![96210782f126492f80cd53ea66e768ce.png][]

客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait\_timeout 控制的，默认值是 8 小时。

如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了。

**数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。**

**建立连接的过程通常是比较复杂的，所以我建议你在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。**

**但是全部使用长连接后，你可能会发现，有些时候 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。**这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。

**怎么解决这个问题呢？**你可以考虑以下两种方案。

*  **定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。**
 *  **如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql\_reset\_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。**

#### 1.1.2 查询缓存 ####

连接建立完成后，你就可以执行 select 语句了。执行逻辑就会来到第二步：查询缓存。

**MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果**。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。

**如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。**你可以看到，如果查询命中缓存，MySQL 不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。但是**大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。**比如，**一个系统配置表，那这张表上的查询才适合使用查询缓存**。好在 **MySQL 也提供了这种“按需使用”的方式。你可以将参数 query\_cache\_type 设置成 DEMAND，这样对于默认的 SQL 语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 SQL\_CACHE 显式指定，**像下面这个语句一样：

mysql> select SQL_CACHE * from T where ID=10；

**需要注意的是，MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开始彻底没有这个功能了。**

#### 1.1.3 分析器 ####

如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要**对 SQL 语句做解析**。

**分析器先会做“词法分析”。**你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列 ID”。做完了这些识别以后，就要做“语法分析”。**根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果你的语句不对，就会收到“You have an error in your SQL syntax”的错误提醒**，比如下面这个语句 select 少打了开头的字母“s”。

mysql> elect * from t where ID=1;
     ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'elect * from t where ID=1' at line 1

**一般语法错误会提示第一个出现错误的位置**，所以你要关注的是紧接“use near”的内容。

#### 1.1.4 优化器 ####

经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。**优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。**比如你执行下面这样的语句，这个语句是执行两个表的 join：

mysql> select * from t1 join t2 using(ID)  where t1.c=10 and t2.d=20;

*  既可以先从表 t1 里面取出 c=10 的记录的 ID 值，再根据 ID 值关联到表 t2，再判断 t2 里面 d 的值是否等于 20。
 *  也可以先从表 t2 里面取出 d=20 的记录的 ID 值，再根据 ID 值关联到 t1，再判断 t1 里面 c 的值是否等于 10。

这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。

优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错等等，没关系，我会在后面的文章中单独展开说明优化器的内容。

#### 1.1.5 执行器 ####

MySQL 通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。

开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误，如下所示 (在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。查询也会在优化器之前调用 precheck 验证权限)。

mysql> select * from T where ID=10;
     ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。比如我们这个例子中的表 T 中，ID 字段没有索引，那么执行器的执行流程是这样的：

1.  调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是，则跳过；如果是，则将这行存在结果集中；
2.  调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
3.  **执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。**

至此，这个语句就执行完成了。

对于有索引的表，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的。

你会**在数据库的慢查询日志中看到一个 rows\_examined 的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟 rows\_examined 并不是完全相同的。**我们后面会专门有一篇文章来讲存储引擎的内部机制，里面会有详细的说明。

**课后问题：**

如果表 T 中没有字段 k，而你执行了这个语句 select \* from T where k=1, 那肯定是会报“不存在这个列”的错误： “Unknown column ‘k’ in ‘where clause’”。你觉得这个错误是在我们上面提到的哪个阶段报出来的呢？

答案：分析器。

## 2. 索引相关【126’】 ##

### 2.1 04 |15’| 深入浅出索引（上） ###

**内容来源：**[04 | 深入浅出索引（上）-极客时间][04 _ _-]

一句话简单来说，**索引的出现其实就是为了提高数据查询的效率**，就像书的目录一样。一本 500 页的书，如果你想快速找到其中的某一个知识点，在不借助目录的情况下，那我估计你可得找一会儿。同样，对于数据库的表而言，索引其实就是它的“目录”。

#### 2.1.1 索引的常见模型 ####

*  **哈希表：**

是一种以键 - 值（key-value）存储数据的结构，我们只要输入待查找的键即 key，就可以找到其对应的值即 Value。哈希的思路很简单，把值放在数组里，用一个哈希函数把 key 换算成一个确定的位置，然后把 value 放在数组的这个位置。

不可避免地，多个 key 值经过哈希函数的换算，会出现同一个值的情况。处理这种情况的一种方法是，拉出一个链表。假设，你现在维护着一个身份证信息和姓名的表，需要根据身份证号查找对应的名字，这时对应的哈希索引的示意图如下所示：

![9bc0c700b9a6895a1a2acfcfa1b025b0.png][]

图中，User2 和 User4 根据身份证号算出来的值都是 N，但没关系，后面还跟了一个链表。假设，这时候你要查 ID\_card\_n2 对应的名字是什么，处理步骤就是：首先，将 ID\_card\_n2 通过哈希函数算出 N；然后，按顺序遍历，找到 User2。

需要注意的是，图中四个 ID\_card\_n 的值并不是递增的，这样做的好处是增加新的 User 时速度会很快，只需要往后追加。但缺点是，因为不是有序的，所以**哈希索引做区间查询的速度是很慢的**。你可以设想下，如果你现在要找身份证号在\[ID\_card\_X, ID\_card\_Y\]这个区间的所有用户，就必须全部扫描一遍了。所以，**哈希表这种结构适用于只有等值查询的场景**，比如 Memcached 及其他一些 NoSQL 引擎。

*  **有序数组：**

**有序数组在等值查询和范围查询场景中的性能就都非常优秀**。还是上面这个根据身份证号查名字的例子，如果我们使用有序数组来实现的话，示意图如下所示：

![9e9c0b76c8d7504f8beb79a41180c450.png][]

这里我们假设身份证号没有重复，这个数组就是按照身份证号递增的顺序保存的。这时候如果你要查 ID\_card\_n2 对应的名字，用二分法就可以快速得到，这个时间复杂度是 O(log(N))。

同时很显然，这个索引结构支持范围查询。你要查身份证号在\[ID\_card\_X, ID\_card\_Y\]区间的 User，可以先用二分法找到 ID\_card\_X（如果不存在 ID\_card\_X，就找到大于 ID\_card\_X 的第一个 User），然后向右遍历，直到查到第一个大于 ID\_card\_Y 的身份证号，退出循环。

如果仅仅看查询效率，有序数组就是最好的数据结构了。但是，在需要更新数据的时候就麻烦了，你往中间插入一个记录就必须得挪动后面所有的记录，成本太高。

所以，**有序数组索引只适用于静态存储引擎**，比如你要保存的是 2017 年某个城市的所有人口信息，这类不会再修改的数据。

*  **二叉搜索树：**

二叉搜索树也是课本里的经典数据结构了。还是上面根据身份证号查名字的例子，如果我们用二叉搜索树来实现的话，示意图如下所示：

![853bc884d11a664619e503c93ce1662c.png][]

**二叉搜索树的特点是：父节点左子树所有结点的值小于父节点的值，右子树所有结点的值大于父节点的值。**这样如果你要查 ID\_card\_n2 的话，按照图中的搜索顺序就是按照 UserA -> UserC -> UserF -> User2 这个路径得到。这个时间复杂度是 O(log(N))。

当然为了维持 O(log(N)) 的查询复杂度，你就需要保持这棵树是平衡二叉树。为了做这个保证，更新的时间复杂度也是 O(log(N))。

树可以有二叉，也可以有多叉。多叉树就是每个节点有多个儿子，儿子之间的大小保证从左到右递增。**二叉树是搜索效率最高的，但是实际上大多数的数据库存储却并不使用二叉树。其原因是，索引不止存在内存中，还要写到磁盘上。**

你可以想象一下一棵 100 万节点的平衡二叉树，树高 20。一次查询可能需要访问 20 个数据块。在机械硬盘时代，从磁盘随机读一个数据块需要 10 ms 左右的寻址时间。也就是说，对于一个 100 万行的表，如果使用二叉树来存储，单独访问一个行可能需要 20 个 10 ms 的时间，这个查询可真够慢的。

**为了让一个查询尽量少地读磁盘，就必须让查询过程访问尽量少的数据块。那么，我们就不应该使用二叉树，而是要使用“N 叉”树。这里，“N 叉”树中的“N”取决于数据块的大小。**

以 InnoDB 的一个整数字段索引为例，这个 N 差不多是 1200。这棵树高是 4 的时候，就可以存 1200 的 3 次方个值，这已经 17 亿了。考虑到树根的数据块总是在内存中的，一个 10 亿行的表上一个整数字段的索引，查找一个值最多只需要访问 3 次磁盘。其实，树的第二层也有很大概率在内存中，那么访问磁盘的平均次数就更少了。

**N 叉树由于在读写上的性能优点，以及适配磁盘的访问模式，已经被广泛应用在数据库引擎中了。**

不管是哈希还是有序数组，或者 N 叉树，它们都是不断迭代、不断优化的产物或者解决方案。数据库技术发展到今天，跳表、LSM 树等数据结构也被用于引擎设计中，这里我就不再一一展开了。

你心里要有个概念，数据库底层存储的核心就是基于这些数据模型的。每碰到一个新数据库，我们需要先关注它的数据模型，这样才能从理论上分析出这个数据库的适用场景。

截止到这里，我用了半篇文章的篇幅和你介绍了不同的数据结构，以及它们的适用场景，你可能会觉得有些枯燥。但是，我建议你还是要多花一些时间来理解这部分内容，毕竟这是数据库处理数据的核心概念之一，在分析问题的时候会经常用到。当你理解了索引的模型后，就会发现在分析问题的时候会有一个更清晰的视角，体会到引擎设计的精妙之处。

**在 MySQL 中，索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。**由于 InnoDB 存储引擎在 MySQL 数据库中使用最为广泛，所以下面我就以 InnoDB 为例，和你分析一下其中的索引模型。

#### **2.1.2 InnoDB 的索引模型** ####

在 InnoDB 中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为**索引组织表**。又因为前面我们提到的，**InnoDB 使用了 B+ 树索引模型**，所以数据都是存储在 B+ 树中的。

**每一个索引在 InnoDB 里面对应一棵 B+ 树**。假设，我们有一个主键列为 ID 的表，表中有字段 k，并且在 k 上有索引。这个表的建表语句是：

mysql> create table T(
     id int primary key, 
     k int not null, 
     name varchar(16),
     index (k))engine=InnoDB;

表中 R1~R5 的 (ID,k) 值分别为 (100,1)、(200,2)、(300,3)、(500,5) 和 (600,6)，两棵树的示例示意图如下。

![e3030fc34806ea235355fd23a72c4c1c.png][]

从图中不难看出，根据叶子节点的内容，**索引类型分为主键索引和非主键索引**。**主键索引的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚簇索引（clustered index）。非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary index）。**根据上面的索引结构说明，我们来讨论一个问题：基于主键索引和普通索引的查询有什么区别？

*  如果语句是 select \* from T where ID=500，即**主键查询方式**，则只需要搜索 ID 这棵 B+ 树；
 *  如果语句是 select \* from T where k=5，即**普通索引查询方式**，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。这个过程称为**回表**。也就是说，**基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。**

#### **2.1.3 索引维护** ####

B+ 树为了维护索引有序性，在插入新值的时候需要做必要的维护。以上面这个图为例，如果插入新的行 ID 值为 700，则只需要在 R5 的记录后面插入一个新记录。如果新插入的 ID 值为 400，就相对麻烦了，需要逻辑上挪动后面的数据，空出位置。

而更糟的情况是，如果 R5 所在的数据页已经满了，根据 B+ 树的算法，这时候需要申请一个新的数据页，然后挪动部分数据过去。这个过程称为**页分裂**。**在这种情况下，性能自然会受影响。除了性能外，页分裂操作还影响数据页的利用率。**原本放在一个页的数据，现在分到两个页中，整体空间利用率降低大约 50%。当然有分裂就有合并。当相邻两个页由于删除了数据，利用率很低之后，会将数据页做**合并**。合并的过程，**可以认为是分裂过程的逆过程**。

基于上面的索引维护过程说明，我们来讨论一个案例：

你可能在一些建表规范里面见到过类似的描述，要求建表语句里一定要有自增主键。当然事无绝对，我们来分析一下哪些场景下应该使用自增主键，而哪些场景下不应该。

**自增主键是指自增列上定义的主键，在建表语句中一般是这么定义的： NOT NULL PRIMARY KEY AUTO\_INCREMENT。插入新记录的时候可以不指定 ID 的值，系统会获取当前 ID 最大值加 1 作为下一条记录的 ID 值。也就是说，自增主键的插入数据模式，正符合了我们前面提到的递增插入的场景。每次插入一条新记录，都是追加操作，都不涉及到挪动其他记录，也不会触发叶子节点的分裂。**

**而有业务逻辑的字段做主键，则往往不容易保证有序插入，这样写数据成本相对较高。**除了考虑性能外，我们还可以从存储空间的角度来看。假设你的表中确实有一个唯一字段，比如字符串类型的身份证号，那应该用身份证号做主键，还是用自增字段做主键呢？由于每个非主键索引的叶子节点上都是主键的值。如果用身份证号做主键，那么每个二级索引的叶子节点占用约 20 个字节，而如果用整型做主键，则只要 4 个字节，如果是长整型（bigint）则是 8 个字节。显然，主**键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。**所以，**从性能和存储空间方面考量，自增主键往往是更合理的选择。**

**有没有什么场景适合用业务字段直接做主键的呢？还是有的。比如，有些业务的场景需求是这样的：只有一个索引；该索引必须是唯一索引。你一定看出来了，这就是典型的 KV 场景。由于没有其他索引，所以也就不用考虑其他索引的叶子节点大小的问题。这时候我们就要优先考虑上一段提到的“尽量使用主键查询”原则，直接将这个索引设置为主键，可以避免每次查询需要搜索两棵树。**

#### **2.1.4 小结** ####

今天，我跟你分析了数据库引擎可用的数据结构，介绍了 InnoDB 采用的 B+ 树结构，以及为什么 InnoDB 要这么选择。**B+ 树能够很好地配合磁盘的读写特性，减少单次查询的磁盘访问次数。由于 InnoDB 是索引组织表，一般情况下我会建议你创建一个自增主键，这样非主键索引占用的空间最小。**但事无绝对，我也跟你讨论了使用业务逻辑字段做主键的应用场景。

#### **2.1.5 问题** ####

对于上面例子中的 InnoDB 表 T，如果你要重建索引 k，你的两个 SQL 语句可以这么写：

alter table T drop index k;
     alter table T add index(k);

如果你要重建主键索引，也可以这么写：

alter table T drop primary key;
     alter table T add primary key(id);

**答案：**

*  **为什么要重建索引？**索引可能因为删除，或者页分裂等原因，导致数据页有空洞，重建索引的过程会创建一个新的索引，把数据按顺序插入，这样页面的利用率最高，也就是索引更紧凑、更省空间。
 *  **重建索引 k 的做法是合理的，可以达到省空间的目的。但是，重建主键的过程不合理。**不论是删除主键还是创建主键，都会将整个表重建。所以连着执行这两个语句的话，第一个语句就白做了。这两个语句，你可以用这个语句代替 ： alter table T engine=InnoDB。

*  **总结：**

1.索引的作用：提高数据查询效率

2.常见索引模型：哈希表、有序数组、搜索树

3.哈希表：键 - 值(key - value)。

4.哈希思路：把值放在数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置

5.哈希冲突的处理办法：链表

6.哈希表适用场景：只有等值查询的场景

7.有序数组：按顺序存储。查询用二分法就可以快速查询，时间复杂度是：O(log(N))

8.有序数组查询效率高，更新效率低

9.有序数组的适用场景：静态存储引擎。

10.二叉搜索树：每个节点的左儿子小于父节点，父节点又小于右儿子

11.二叉搜索树：查询时间复杂度O(log(N))，更新时间复杂度O(log(N))

12.数据库存储大多不适用二叉树，因为树高过高，会适用N叉树

13.InnoDB中的索引模型：B+Tree

14.索引类型：主键索引、非主键索引 主键索引的叶子节点存的是整行的数据(聚簇索引)，非主键索引的叶子节点内容是主键的值(二级索引)

15.主键索引和普通索引的区别：主键索引只要搜索ID这个B+Tree即可拿到数据。普通索引先搜索索引拿到主键值，再到主键索引树搜索一次(回表)

16.一个数据页满了，按照B+Tree算法，新增加一个数据页，叫做页分裂，会导致性能下降。空间利用率降低大概50%。当相邻的两个数据页利用率很低的时候会做数据页合并，合并的过程是分裂过程的逆过程。

17.从性能和存储空间方面考量，自增主键往往是更合理的选择。 思考题： 如果删除，新建主键索引，会同时去修改普通索引对应的主键索引，性能消耗比较大。 删除重建普通索引貌似影响不大，不过要注意在业务低谷期操作，避免影响业务。

### 2.2 05 |10’| 深入浅出索引（下） ###

**内容来源：**[05 | 深入浅出索引（下）-极客时间][05 _ _-]

**创建表T：**

mysql> create table T (
         ID int primary key,
         k int NOT NULL DEFAULT 0, 
         s varchar(16) NOT NULL DEFAULT '',
         index k(k)
     )engine=InnoDB;
     
     insert into T values
     (100,1,'aa'),
     (200,2,'bb'),
     (300,3,'cc'),
     (500,5,'ee'),
     (600,6,'ff'),
     (700,7,'gg');

**索引结构如下：**

![5dd3f5d240b4a6a7643187ff77305226.png][]

如果执行 select \* from T where k between 3 and 5，需要执行几次树的搜索操作，会扫描多少行？

这条 SQL 查询语句的执行流程：

1.  在 k 索引树上找到 k=3 的记录，取得 ID = 300；
2.  再到 ID 索引树查到 ID=300 对应的 R3；
3.  在 k 索引树取下一个值 k=5，取得 ID=500；
4.  再回到 ID 索引树查到 ID=500 对应的 R4；
5.  在 k 索引树取下一个值 k=6，不满足条件，循环结束。

在这个过程中，回到主键索引树搜索的过程，我们称为**回表**。可以看到，这个查询过程读了 k 索引树的 3 条记录（步骤 1、3 和 5），回表了两次（步骤 2 和 4）。

在这个例子中，由于查询结果所需要的数据只在主键索引上有，所以不得不回表。那么，有没有可能经过索引优化，避免回表过程呢？

#### 覆盖索引 ####

如果执行的语句是 select ID from T where k between 3 and 5，这时只需要查 ID 的值，而 ID 的值已经在 k 索引树上了，因此可以直接提供查询结果，不需要回表。也就是说，在这个查询里面，索引 k 已经“覆盖了”我们的查询需求，我们称为**覆盖索引**。

**由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。**

需要注意的是，在引擎内部使用覆盖索引在索引 k 上其实读了三个记录，R3~R5（对应的索引 k 上的记录项），但是对于 MySQL 的 Server 层来说，它就是找引擎拿到了两条记录，因此 MySQL 认为扫描行数是 2。

**创建市民表tuser：**

CREATE TABLE `tuser` (
       `id` int(11) NOT NULL,
       `id_card` varchar(32) DEFAULT NULL,
       `name` varchar(32) DEFAULT NULL,
       `age` int(11) DEFAULT NULL,
       `ismale` tinyint(1) DEFAULT NULL,
       PRIMARY KEY (`id`),
       KEY `id_card` (`id_card`),
       KEY `name_age` (`name`,`age`)
     ) ENGINE=InnoDB

在一个市民信息表上，是否有必要将身份证号和名字建立联合索引？

我们知道，身份证号是市民的唯一标识。也就是说，如果有根据身份证号查询市民信息的需求，我们只要在身份证号字段上建立索引就够了。而再建立一个（身份证号、姓名）的联合索引，是不是浪费空间？

如果现在有一个高频请求，要根据市民的身份证号查询他的姓名，这个联合索引就有意义了。它可以在这个高频请求上用到覆盖索引，不再需要回表查整行记录，减少语句的执行时间。

当然，索引字段的维护总是有代价的。因此，在建立冗余索引来支持覆盖索引时就需要权衡考虑了。这正是业务 DBA，或者称为业务数据架构师的工作。

#### 最左前缀原则 ####

看到这里你一定有一个疑问，如果为每一种查询都设计一个索引，索引是不是太多了。如果我现在要按照市民的身份证号去查他的家庭地址呢？虽然这个查询需求在业务中出现的概率不高，但总不能让它走全表扫描吧？反过来说，单独为一个不频繁的请求创建一个（身份证号，地址）的索引又感觉有点浪费。应该怎么做呢？B+ 树这种索引结构，可以利用索引的“最左前缀”，来定位记录。为了直观地说明这个概念，我们用（name，age）这个联合索引来分析。

![163c2c0e095791d126f96155e52c1274.jpeg][]

可以看到，索引项是按照索引定义里面出现的字段顺序排序的。

当你的逻辑需求是查到所有名字是“张三”的人时，可以快速定位到 ID4，然后向后遍历得到所有需要的结果；如果你要查的是所有名字第一个字是“张”的人，你的 SQL 语句的条件是"where name like ‘张 %’"。这时，你也能够用上这个索引，查找到第一个符合条件的记录是 ID3，然后向后遍历，直到不满足条件为止。

可以看到，不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。这个**最左前缀可以是联合索引的最左 N 个字段，也可以是字符串索引的最左 M 个字符。**

基于上面对最左前缀索引的说明，我们来讨论一个问题：**在建立联合索引的时候，如何安排索引内的字段顺序，这里我们的评估标准是索引的复用能力。**因为可以支持最左前缀，所以当已经有了 (a,b) 这个联合索引后，一般就不需要单独在 a 上建立索引了。因此，**第一原则是，如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。**所以现在你知道了，这段开头的问题里，我们要为高频请求创建 (身份证号，姓名）这个联合索引，并用这个索引支持“根据身份证号查询地址”的需求。

那么，如果既有联合查询，又有基于 a、b 各自的查询呢？查询条件里面只有 b 的语句，是无法使用 (a,b) 这个联合索引的，这时候你不得不维护另外一个索引，也就是说你需要同时维护 (a,b)、(b) 这两个索引。这时候，我们要考虑的原则就是空间了。比如上面这个市民表的情况，name 字段是比 age 字段大的 ，那我就建议你创建一个（name,age) 的联合索引和一个 (age) 的单字段索引。

#### 索引下推 ####

上一段我们说到满足最左前缀原则的时候，最左前缀可以用于在索引中定位记录。这时，你可能要问，那些不符合最左前缀的部分，会怎么样呢？我们还是以市民表的联合索引（name, age）为例。如果现在有一个需求：检索出表中“名字第一个字是张，而且年龄是 10 岁的所有男孩”。那么，SQL 语句是这么写的：

mysql> select * from tuser where name like '张%' and age=10 and ismale=1;

你已经知道了前缀索引规则，所以这个语句在搜索索引树的时候，只能用 “张”，找到第一个满足条件的记录 ID3。当然，这还不错，总比全表扫描要好。然后呢？当然是判断其他条件是否满足。在 **MySQL 5.6 之前**，只能从 ID3 开始一个个**回表**。到主键索引上找出数据行，再对比字段值。而 **MySQL 5.6 引入的索引下推优化（index condition pushdown)， 可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。**

**无索引下推执行流程：图中的每一个虚线箭头表示回表一次。**

![7395f966b087ea31e404226a71ebe48e.jpeg][]

在 (name,age) 索引里面我特意去掉了 age 的值，因为这个过程 InnoDB 并不会去看 age 的值，只是按顺序把“name 第一个字是’张’”的记录一条条取出来回表。因此，需要回表 4 次。

**索引下推执行流程:**

![a217eb877c633d600289a7133425dbab.jpeg][]

InnoDB 在 (name,age) 索引内部就判断了 age 是否等于 10，对于不等于 10 的记录，直接判断并跳过。在我们的这个例子中，只需要对 ID4、ID5 这两条记录回表取数据判断，就只需要回表 2 次。

#### 小结 ####

今天这篇文章，我和你继续讨论了数据库索引的概念，包括了覆盖索引、前缀索引、索引下推。你可以看到，在满足语句需求的情况下， 尽量少地访问资源是数据库设计的重要原则之一。我们在使用数据库的时候，尤其是在设计表结构时，也要以减少资源消耗作为目标。

**补充：**

*  主键也是一种索引
 *  树高取决于叶子数（数据行数）和N叉树中的N，其中N是由页大小和索引大小决定的。
 *  覆盖索引：如果查询条件使用的是普通索引（或是联合索引的最左原则字段），查询结果是联合索引的字段或是主键，不用回表操作，直接返回结果，减少IO磁盘读写整行数据；
 *  最左前缀：联合索引的最左N个字段，也可以是字符串索引的最左M个字符
 *  联合索引：根据创建联合索引的顺序，以最左原则进行where检索，比如（age，name）以age=1 或 age= 1 and name=‘张三’可以使用索引，单以name=‘张三’ 不会使用索引，考虑到存储空间的问题，还请根据业务需求，将查找频繁的数据进行靠左创建索引。
 *  索引下推：like 'hello%’and age >10 检索，MySQL5.6版本之前，会对匹配的数据进行回表查询；5.6版本后，会先过滤掉age<10的数据，再进行回表查询，减少回表率，提升检索速度。

#### 问题： ####

实际上主键索引也是可以使用多个字段的。DBA 小吕在入职新公司的时候，就发现自己接手维护的库里面，有这么一个表，表结构定义类似这样的：

CREATE TABLE `geek` (
       `a` int(11) NOT NULL,
       `b` int(11) NOT NULL,
       `c` int(11) NOT NULL,
       `d` int(11) NOT NULL,
       PRIMARY KEY (`a`,`b`),
       KEY `c` (`c`),
       KEY `ca` (`c`,`a`),
       KEY `cb` (`c`,`b`)
     ) ENGINE=InnoDB;

公司的同事告诉他说，由于历史原因，这个表需要 a、b 做联合主键，这个小吕理解了。但是，学过本章内容的小吕又纳闷了，既然主键包含了 a、b 这两个字段，那意味着单独在字段 c 上创建一个索引，就已经包含了三个字段了呀，为什么要创建“ca”“cb”这两个索引？同事告诉他，是因为他们的业务里面有这样的两种语句：

select * from geek where c=N order by a limit 1;
     select * from geek where c=N order by b limit 1;

这位同事的解释对吗，为了这两个查询模式，这两个索引是否都是必须的？为什么呢？

**答案：**

主键 a，b 的聚簇索引组织顺序相当于 order by a,b ，也就是先按 a 排序，再按 b 排序，c 无序：

a  |  b  | c |  d  |
       1     2    3    d
       1     3    2    d
       1     4    3    d
       2     1    3    d
       2     2    2    d
       2     3    4    d

索引 ca 的组织是先按 c 排序，再按 a 排序，同时记录主键：

– c-|–a-|–主键部分b-| （注意，这里不是 ab，而是只有 b）
       2   1          3
       2   2          2
       3   1          2
       3   1          4
       3   2          1
       4   2          3

这个跟索引 c 的数据是一模一样的。 索引 cb 的组织是先按 c 排序，在按 b 排序，同时记录主键：

–c-|–b-|–主键部分a-|（同上）
       2   2          2
       2   3          1
       3   1          2
       3   2          1
       3   4          1
       4   3          2

所以，结论是 ca 可以去掉，cb 需要保留。

### 2.3 09 |16’| 普通索引和唯一索引，应该怎么选择？ ###

**内容来源：**[09 | 普通索引和唯一索引，应该怎么选择？-极客时间][09 _ _-]

假设你在维护一个市民系统，每个人都有一个唯一的身份证号，而且业务代码已经保证了不会写入两个重复的身份证号。如果市民系统需要按照身份证号查姓名，就会执行类似这样的 SQL 语句：

select name from CUser where id_card = 'xxxxxxxyyyyyyzzzzz';

所以，你一定会考虑在 id\_card 字段上建索引。

**由于身份证号字段比较大，我不建议你把身份证号当做主键**，那么现在你有两个选择，要么给 id\_card 字段创建唯一索引，要么创建一个普通索引。如果业务代码已经保证了不会写入重复的身份证号(身份证号唯一），那么这两个选择逻辑上都是正确的。现在我要问你的是，从性能的角度考虑，你选择唯一索引还是普通索引呢？选择的依据是什么呢？

**举例：**假设字段 k 上的值都不重复

![39ad8559472e375c4fe07d4313222637.png][]

#### 查询过程 ####

假设，执行查询的语句是

select id from T where k=5

**查询过程为：**先通过 B+ 树从树根开始，按层搜索到叶子节点，也就是图中右下角的这个数据页，然后可以认为数据页内部通过二分法来定位记录。

*  对于普通索引来说，查找到满足条件的第一个记录 (5,500) 后，需要查找下一个记录，直到碰到第一个不满足 k=5 条件的记录。
 *  对于唯一索引来说，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索。

那么，这个不同带来的性能差距会有多少呢？答案是，微乎其微。

你知道的，InnoDB 的数据是按数据页为单位来读写的。也就是说，当需要读一条记录的时候，并不是将这个记录本身从磁盘读出来，而是以页为单位，将其整体读入内存。在 InnoDB 中，每个数据页的大小默认是 16KB。因为引擎是按页读写的，所以说，当找到 k=5 的记录的时候，它所在的数据页就都在内存里了。那么，对于普通索引来说，要多做的那一次“查找和判断下一条记录”的操作，就只需要一次指针寻找和一次计算。当然，如果 k=5 这个记录刚好是这个数据页的最后一个记录，那么要取下一个记录，必须读取下一个数据页，这个操作会稍微复杂一些。但是，我们之前计算过，对于整型字段，一个数据页可以放近千个 key，因此出现这种情况的概率会很低。所以，我们计算平均性能差异时，仍可以认为这个操作成本对于现在的 CPU 来说可以忽略不计。

**综上，在查询上普通索引与唯一索引性能相差很小。**

#### 更新过程 ####

为了说明普通索引和唯一索引对更新语句性能的影响这个问题，我需要先跟你介绍一下 **change buffer**。

**当需要更新一个数据页时，如果数据页在内存中，直接更新；如果这个数据页没在内存中，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性**。

**需要说明的是，虽然名字叫作 change buffer，实际上它是可以持久化的数据。也就是说，change buffer 在内存中有拷贝，也会被写入到磁盘上。**将 change buffer 中的操作应用到原数据页，得到最新结果的过程称为 merge。除了访问这个数据页会触发 merge 外，系统有后台线程会定期 merge。在数据库正常关闭（shutdown）的过程中，也会执行 merge 操作。显然，如果能够将更新操作先记录在 change buffer，减少读磁盘，语句的执行速度会得到明显的提升。而且，数据读入内存是需要占用 buffer pool 的，所以这种方式还能够避免占用内存，提高内存利用率。

那么，**什么条件下可以使用 change buffer 呢？对于唯一索引来说，所有的更新操作都要先判断这个操作是否违反唯一性约束。**比如，要插入 (4,400) 这个记录，就要先判断现在表中是否已经存在 k=4 的记录，而这必须要将数据页读入内存才能判断。如果都已经读入到内存了，那直接更新内存会更快，就没必要使用 change buffer 了。因此，**唯一索引的更新就不能使用 change buffer，实际上也只有普通索引可以使用。change buffer 用的是 buffer pool 里的内存，因此不能无限增大。change buffer 的大小，可以通过参数 innodb\_change\_buffer\_max\_size 来动态设置。这个参数设置为 50 的时候，表示 change buffer 的大小最多只能占用 buffer pool 的 50%。**

现在，你已经理解了 change buffer 的机制，那么我们再一起来看看如果要在这张表中插入一个新记录 (4,400) 的话，InnoDB 的处理流程是怎样的：

*  第一种情况是，这个记录要更新的目标页在内存中。
    
     *  对于唯一索引来说，找到 3 和 5 之间的位置，判断到没有冲突，插入这个值，语句执行结束；
     *  对于普通索引来说，找到 3 和 5 之间的位置，插入这个值，语句执行结束。
        
        这样看来，普通索引和唯一索引对更新语句性能影响的差别，只是一个判断，只会耗费微小的 CPU 时间。但这不是我们关注的重点。
 *  第二种情况是，这个记录要更新的目标页不在内存中。
    
     *  对于唯一索引来说，需要将数据页读入内存，判断到没有冲突，插入这个值，语句执行结束；
     *  对于普通索引来说，则是将更新记录在 change buffer，语句执行就结束了。
        
        **将数据从磁盘读入内存涉及随机 IO 的访问，是数据库里面成本最高的操作之一。change buffer 因为减少了随机磁盘访问，所以对更新性能的提升是会很明显的。**

之前我就碰到过一件事儿，有个 DBA 的同学跟我反馈说，他负责的某个业务的库内存命中率突然从 99% 降低到了 75%，整个系统处于阻塞状态，更新语句全部堵住。而探究其原因后，我发现这个业务有大量插入数据的操作，而他在前一天把其中的某个普通索引改成了唯一索引。

#### change buffer 的使用场景 ####

通过上面的分析，你已经清楚了使用 change buffer 对更新过程的加速作用，也清楚了 **change buffer 只限于用在普通索引的场景下，而不适用于唯一索引**。那么，现在有一个问题就是：普通索引的所有场景，使用 change buffer 都可以起到加速作用吗？因为 merge 的时候是真正进行数据更新的时刻，而 change buffer 的主要目的就是将记录的变更动作缓存下来，所以在一个数据页做 merge 之前，change buffer 记录的变更越多（也就是这个页面上要更新的次数越多），收益就越大。因此，**对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer 的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。**反过来，**假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在 change buffer，但之后由于马上要访问这个数据页，会立即触发 merge 过程。这样随机访问 IO 的次数不会减少，反而增加了 change buffer 的维护代价。所以，对于这种业务模式来说，change buffer 反而起到了副作用。**

#### 索引选择和实践 ####

回到我们文章开头的问题，**普通索引和唯一索引应该怎么选择。其实，这两类索引在查询能力上是没差别的，主要考虑的是对更新性能的影响。所以，我建议你尽量选择普通索引。如果所有的更新后面，都马上伴随着对这个记录的查询，那么你应该关闭 change buffer。而在其他情况下，change buffer 都能提升更新性能。在实际使用中，你会发现，普通索引和 change buffer 的配合使用，对于数据量大的表的更新优化还是很明显的。特别地，在使用机械硬盘时，change buffer 这个机制的收效是非常显著的。所以，当你有一个类似“历史数据”的库，并且出于成本考虑用的是机械硬盘时，那你应该特别关注这些表里的索引，尽量使用普通索引，然后把 change buffer 尽量开大，以确保这个“历史数据”表的数据写入速度足够快。**

#### change buffer 和 redo log ####

理解了 change buffer 的原理，你可能会联想到我在前面文章中和你介绍过的 redo log 和 WAL。在前面文章的评论中，我发现有同学混淆了 redo log 和 change buffer。**WAL 提升性能的核心机制，也的确是尽量减少随机读写**，这两个概念确实容易混淆。所以，这里我把它们放到了同一个流程里来说明，便于你区分这两个概念。

现在，我们要在表上执行这个插入语句：

mysql> insert into t(id,k) values(id1,k1),(id2,k2);

这里，我们假设当前 k 索引树的状态，查找到位置后，k1 所在的数据页在内存 (InnoDB buffer pool) 中，k2 所在的数据页不在内存中。如图 2 所示是带 change buffer 的更新状态图。

![cf322c58852d774e4d3c986a59f7203a.png][]

分析这条更新语句，你会发现它涉及了四个部分：内存、redo log（ib\_log\_fileX）、 数据表空间（t.ibd）、系统表空间（ibdata1）。这条更新语句做了如下的操作（按照图中的数字顺序）：

*  Page 1 在内存中，直接更新内存；
 *  Page 2 没有在内存中，就在内存的 change buffer 区域，记录下“我要往 Page 2 插入一行”这个信息；
 *  将上述两个动作记入 redo log 中（图中 3 和 4）。

做完上面这些，事务就可以完成了。所以，你会看到，执行这条更新语句的成本很低，就是写了两处内存，然后写了一处磁盘（两次操作合在一起写了一次磁盘），而且还是顺序写的。同时，图中的两个虚线箭头，是后台操作，不影响更新的响应时间。那在这之后的读请求，要怎么处理呢？比如，我们现在要执行 select \* from t where k in (k1, k2)。这里，我画了这两个读请求的流程图。如果读语句发生在更新语句后不久，内存中的数据都还在，那么此时的这两个读操作就与系统表空间（ibdata1）和 redo log（ib\_log\_fileX）无关了。所以，我在图中就没画出这两部分。

![278103b8e5bd5ab43139250a3e2dbc27.png][]

从图中可以看到：

*  读 Page 1 的时候，直接从内存返回。有几位同学在前面文章的评论中问到，WAL 之后如果读数据，是不是一定要读盘，是不是一定要从 redo log 里面把数据更新以后才可以返回？其实是不用的。你可以看一下图 3 的这个状态，虽然磁盘上还是之前的数据，但是这里直接从内存返回结果，结果是正确的。

*  要读 Page 2 的时候，需要把 Page 2 从磁盘读入内存中，然后应用 change buffer 里面的操作日志，生成一个正确的版本并返回结果。

可以看到，直到需要读 Page 2 的时候，这个数据页才会被读入内存。所以，**如果要简单地对比这两个机制在提升更新性能上的收益的话，redo log 主要节省的是随机写磁盘的 IO 消耗（转成顺序写），而 change buffer 主要节省的则是随机读磁盘的 IO 消耗。**

#### 小结 ####

今天，我从普通索引和唯一索引的选择开始，和你分享了数据的查询和更新过程，然后说明了 change buffer 的机制以及应用场景，最后讲到了索引选择的实践。由于唯一索引用不上 change buffer 的优化机制，因此如果业务可以接受，从性能角度出发我建议你优先考虑非唯一索引。

#### 思考 ####

通过图 2 你可以看到，change buffer 一开始是写内存的，那么如果这个时候机器掉电重启，会不会导致 change buffer 丢失呢？change buffer 丢失可不是小事儿，再从磁盘读入数据可就没有了 merge 过程，就等于是数据丢失了。会不会出现这种情况呢？

**答案：**不会丢失，虽然是只更新内存，但是在事务提交的时候，我们把 change buffer 的操作也记录到 redo log 里了，所以崩溃恢复的时候，change buffer 也能找回来。

1.  change buffer中分两部分，一部分是本次写入未写完的，一部分是已经写入完成的。
2.  针对未写完的，此部分操作还未写入redo log，因此事务还未提交commit，所以没影响。
3.  针对已经写完成的，可以通过redo log来进行恢复。
    
    **注意：先change buffer，在redo log**。

#### 补充 ####

1.  **评论区大家对“是否使用唯一索引”有比较多的讨论，主要是纠结在“业务可能无法确保”的情况：**

*  首先，业务正确性优先。咱们这篇文章的前提是“业务代码已经保证不会写入重复数据”的情况下，讨论性能问题。如果业务不能保证，或者业务就是要求数据库来做约束，那么没得选，必须创建唯一索引。这种情况下，本篇文章的意义在于，如果碰上了大量插入数据慢、内存命中率低的时候，可以给你多提供一个排查思路。
 *  然后，在一些“归档库”的场景，你是可以考虑使用普通索引的。比如，线上数据只需要保留半年，然后历史数据保存在归档库。这时候，归档数据已经是确保没有唯一键冲突了。要提高归档效率，可以考虑把表里面的唯一索引改成普通索引。

1.  **merge 的过程是否会把数据直接写回磁盘？**
    
    merge 的执行流程是这样的：
    
     *  从磁盘读入数据页到内存（老版本的数据页）；
     *  从 change buffer 里找出这个数据页的 change buffer 记录 (可能有多个），依次应用，得到新版数据页；
     *  写 redo log。这个 redo log 包含了数据的变更和 change buffer 的变更，到这里 merge 过程就结束了。
        
        这时候，数据页和内存中 change buffer 对应的磁盘位置都还没有修改，属于脏页，之后各自刷回自己的物理数据，就是另外一个过程了。
2.  **change buffer的前身是insert buffer，只能对insert 操作优化；后来升级后增加了对update/delete的支持，名字也改叫change buffer。**
3.  **系统表空间就是用来放系统信息的，比如数据字典什么的，对应的磁盘文件是ibdata1, 数据表空间就是一个个的表数据文件，对应的磁盘文件就是 表名.ibd。**
4.  **锁是一个单独的数据结构，如果数据页上有锁，change buffer 在判断“是否能用”的时候，就会认为否。**
5.  **change buffer跟普通数据页一样也是存在磁盘里，区别在于changebuffer是存在系统表空间ibdata1里；**
6.  **redolog有两种，一种记录普通数据页的改动，一种记录changebuffer的改动。只要内存里脏页（innodb buffer pool）里的数据发生了变化，就一定会记录两种中的前一种redolog （对数据的修改记录在change buffer里，内存里是没有这个物理页的，不存在脏页）。真正对磁盘数据页的修改是通过将内存里脏页的数据刷回磁盘来完成的，而不是根据redolog。**

### 2.4 10 |18’| MySQL为什么有时候会选错索引？ ###

**内容来源：**[10 | MySQL为什么有时候会选错索引？-极客时间][10 _ MySQL_-]

**举例：**先建一个简单的表，表里有 a、b 两个字段，并分别建上索引：

CREATE TABLE `t` (
       `id` int(11) NOT NULL AUTO_INCREMENT,
       `a` int(11) DEFAULT NULL,
       `b` int(11) DEFAULT NULL,
       PRIMARY KEY (`id`),
       KEY `a` (`a`),
       KEY `b` (`b`)
     ) ENGINE=InnoDB;

然后，我们往表 t 中插入 10 万行记录，取值按整数递增，即：(1,1,1)，(2,2,2)，(3,3,3) 直到 (100000,100000,100000)。我是用存储过程来插入数据的，这里我贴出来方便你复现：

delimiter ;;
     create procedure idata()
     begin
       declare i int;
       set i=1;
       while(i<=100000)do
         insert into t values(i, i, i);
         set i=i+1;
       end while;
     end;;
     delimiter ;
     call idata();

接下来执行SQL查询：

mysql> select * from t where a between 10000 and 20000;

由于a上有索引，必然使用索引a进行查询，可以使用 explain 命令看到的这条语句的执行情况：

![c5ef904458392c2fb9fe0bfc78a711d9.png][]

从图 1 看上去，这条查询语句的执行也确实符合预期，key 这个字段值是’a’，表示优化器选择了索引 a。不过别急，这个案例不会这么简单。在我们已经准备好的包含了 10 万行数据的表上，我们再做如下操作：

![ec6ce7e9b533624657f85d60c1b199b0.png][]

这里，session A 的操作你已经很熟悉了，它就是开启了一个事务。随后，session B 把数据都删除后，又调用了 idata 这个存储过程，插入了 10 万行数据。这时候，session B 的查询语句 select \* from t where a between 10000 and 20000 就不会再选择索引 a 了。我们可以通过慢查询日志（slow log）来查看一下具体的执行情况。为了说明优化器选择的结果是否正确，我增加了一个对照，即：使用 force index(a) 来让优化器强制使用索引 a（这部分内容，我还会在这篇文章的后半部分中提到）。下面的三条 SQL 语句，就是这个实验过：

set long_query_time=0;
     select * from t where a between 10000 and 20000; /*Q1*/
     select * from t force index(a) where a between 10000 and 20000;/*Q2*/

第一句，是将慢查询日志的阈值设置为 0，表示这个线程接下来的语句都会被记录入慢查询日志中； 第二句，Q1 是 session B 原来的查询； 第三句，Q2 是加了 force index(a) 来和 session B 原来的查询语句执行情况对比。

如图 3 所示是这三条 SQL 语句执行完成后的慢查询日志：

![859353eaaa9abdacdad74b72e86ec7e8.png][]

可以看到，Q1 扫描了 10 万行，显然是走了全表扫描，执行时间是 40 毫秒。Q2 扫描了 10001 行，执行了 21 毫秒。也就是说，我们在没有使用 force index 的时候，MySQL 用错了索引，导致了更长的执行时间。

这个例子对应的是我们平常不断地删除历史数据和新增数据的场景。这时，MySQL 竟然会选错索引，是不是有点奇怪呢？今天，我们就从这个奇怪的结果说起吧。

#### 优化器的逻辑 ####

在第一篇文章中，我们就提到过，选择索引是优化器的工作。而优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。**在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少。当然，扫描行数并不是唯一的判断标准，优化器还会结合是否使用临时表、是否排序等因素进行综合判断。**我们这个简单的查询语句并没有涉及到临时表和排序，所以 MySQL 选错索引肯定是在判断扫描行数的时候出问题了。那么，问题就是：扫描行数是怎么判断的？

MySQL 在真正开始执行语句之前，并不能精确地知道满足这个条件的记录有多少条，而只能根据统计信息来估算记录数。这个统计信息就是索引的“区分度”。显然，**一个索引上不同的值越多，这个索引的区分度就越好。而一个索引上不同的值的个数，我们称之为“基数”（cardinality）。也就是说，这个基数越大，索引的区分度越好。**我们可以使用 show index 方法，看到一个索引的基数。如图 4 所示，就是表 t 的 show index 的结果 ：

![8f9ecd87a69f207eddf657b45c89be89.png][]

虽然这个表的每一行的三个字段值都是一样的，但是在统计信息中，这三个索引的基数值并不同，而且其实都不准确。那么，MySQL 是怎样得到索引的基数的呢？这里，我给你简单介绍一下 MySQL 采样统计的方法。**为什么要采样统计呢？因为把整张表取出来一行行统计，虽然可以得到精确的结果，但是代价太高了，所以只能选择“采样统计”。采样统计的时候，InnoDB 默认会选择 N 个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。而数据表是会持续更新的，索引统计信息也不会固定不变。所以，当变更的数据行数超过 1/M 的时候，会自动触发重新做一次索引统计。在 MySQL 中，有两种存储索引统计的方式，可以通过设置参数 innodb\_stats\_persistent 的值来选择：**

*  **设置为 on 的时候，表示统计信息会持久化存储。这时，默认的 N 是 20，M 是 10。**
 *  **设置为 off 的时候，表示统计信息只存储在内存中。这时，默认的 N 是 8，M 是 16。**

由于是采样统计，所以不管 N 是 20 还是 8，这个基数都是很容易不准的。

但这还不是全部，你可以从图 4 中看到，这次的索引统计值（cardinality 列）虽然不够精确，但大体上还是差不多的，选错索引一定还有别的原因。**其实索引统计只是一个输入，对于一个具体的语句来说，优化器还要判断，执行这个语句本身要扫描多少行。**接下来，我们再一起看看优化器预估的，这两个语句的扫描行数是多少：

![8d6f933ed9fa647090b2c5e2c36388e3.png][]

rows 这个字段表示的是预计扫描行数。其中，Q1 的结果还是符合预期的，rows 的值是 104620；但是 Q2 的 rows 值是 37116，偏差就大了。而图 1 中我们用 explain 命令看到的 rows 是只有 10001 行，是这个偏差误导了优化器的判断。到这里，可能你的第一个疑问不是为什么不准，而是优化器为什么放着扫描 37000 行的执行计划不用，却选择了扫描行数是 100000 的执行计划呢？这是因为如果使用索引 a，每次从索引 a 上拿到一个值，都要回到主键索引上查出整行数据，这个代价优化器也要算进去的。而如果选择扫描 10 万行，是直接在主键索引上扫描的，没有额外的代价。优化器会估算这两个选择的代价，从结果看来，优化器认为直接扫描主键索引更快。

当然，从执行时间看来，这个选择并不是最优的。使用普通索引需要把回表的代价算进去，在图 1 执行 explain 的时候，也考虑了这个策略的代价 ，但图 1 的选择是对的。也就是说，这个策略并没有问题。所以冤有头债有主，**MySQL 选错索引，这件事儿还得归咎到没能准确地判断出扫描行数。至于为什么会得到错误的扫描行数，这个原因就作为课后问题，留给你去分析了。**既然是统计信息不对，那就修正。**analyze table t 命令，可以用来重新统计索引信息**。我们来看一下执行效果。

![443ca71bb3c35c7a0723064c832ba69d.png][]

这回对了。所以在实践中，如果你发现 explain 的结果预估的 rows 值跟实际情况差距比较大，可以采用这个方法来处理。其实，如果只是索引统计不准确，通过 analyze 命令可以解决很多问题，但是前面我们说了，优化器可不止是看扫描行数。依然是基于这个表 t，我们看看另外一个语句：

mysql> select * from t where (a between 1 and 1000)  and (b between 50000 and 100000) order by b limit 1;

从条件上看，这个查询没有符合条件的记录，因此会返回空集合。在开始执行这条语句之前，你可以先设想一下，如果你来选择索引，会选择哪一个呢？为了便于分析，我们先来看一下 a、b 这两个索引的结构图。

![28634bc5ed03623296363b7f5fe44c19.png][]

如果使用索引 a 进行查询，那么就是扫描索引 a 的前 1000 个值，然后取到对应的 id，再到主键索引上去查出每一行，然后根据字段 b 来过滤。显然这样需要扫描 1000 行。如果使用索引 b 进行查询，那么就是扫描索引 b 的最后 50001 个值，与上面的执行过程相同，也是需要回到主键索引上取值再判断，所以需要扫描 50001 行。所以你一定会想，如果使用索引 a 的话，执行速度明显会快很多。那么，下面我们就来看看到底是不是这么一回事儿。图 8 是执行 explain 的结果：

mysql> explain select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;

![f8dc05dc6c9d56d6b92e27aeacc571ab.png][]

可以看到，返回结果中 key 字段显示，这次优化器选择了索引 b，而 rows 字段显示需要扫描的行数是 50198。从这个结果中，你可以得到两个结论：

*  扫描行数的估计值依然不准确；
 *  这个例子里 MySQL 又选错了索引。

#### 索引选择异常和处理 ####

其实大多数时候优化器都能找到正确的索引，但偶尔你还是会碰到我们上面举例的这两种情况：**原本可以执行得很快的 SQL 语句，执行速度却比你预期的慢很多，你应该怎么办呢？**

一种方法是，像我们第一个例子一样，**采用 force index 强行选择一个索引。MySQL 会根据词法解析的结果分析出可能可以使用的索引作为候选项，然后在候选列表中依次判断每个索引需要扫描多少行。如果 force index 指定的索引在候选索引列表中，就直接选择这个索引，不再评估其他索引的执行代价。**

我们来看看第二个例子。刚开始分析时，我们认为选择索引 a 会更好。现在，我们就来看看执行效果：

![6fcdc6ad7d8921cd2b31cb591ec80cbe.png][]

可以看到，原本语句需要执行 2.23 秒，而当你使用 force index(a) 的时候，只用了 0.05 秒，比优化器的选择快了 40 多倍。也就是说，优化器没有选择正确的索引，force index 起到了“矫正”的作用。不过很多程序员不喜欢使用 force index，一来这么写不优美，二来如果索引改了名字，这个语句也得改，显得很麻烦。而且如果以后迁移到别的数据库的话，这个语法还可能会不兼容。但**其实使用 force index 最主要的问题还是变更的及时性。因为选错索引的情况还是比较少出现的，所以开发的时候通常不会先写上 force index。而是等到线上出现问题的时候，你才会再去修改 SQL 语句、加上 force index。但是修改之后还要测试和发布，对于生产系统来说，这个过程不够敏捷。**

所以，**数据库的问题最好还是在数据库内部来解决**。那么，在数据库里面该怎样解决呢？既然优化器放弃了使用索引 a，说明 a 还不够合适，所以第二种方法就是，我们可以**考虑修改语句，引导 MySQL 使用我们期望的索引**。比如，在这个例子里，显然把“order by b limit 1” 改成 “order by b,a limit 1” ，语义的逻辑是相同的。我们来看看改之后的效果：

![4651f9bb4c98907ff75e19340be8de56.png][]

之前优化器选择使用索引 b，是因为它认为使用索引 b 可以避免排序（b 本身是索引，已经是有序的了，如果选择索引 b 的话，不需要再做排序，只需要遍历），所以即使扫描行数多，也判定为代价更小。现在 order by b,a 这种写法，要求按照 b,a 排序，就意味着使用这两个索引都需要排序。因此，扫描行数成了影响决策的主要条件，于是此时优化器选了只需要扫描 1000 行的索引 a。当然，这种修改并不是通用的优化手段，只是刚好在这个语句里面有 limit 1，因此如果有满足条件的记录， order by b limit 1 和 order by b,a limit 1 都会返回 b 是最小的那一行，逻辑上一致，才可以这么做。如果你觉得修改语义这件事儿不太好，这里还有一种改法，图 11 是执行效果：

mysql> select * from  (select * from t where (a between 1 and 1000)  and (b between 50000 and 100000) order by b limit 100)alias limit 1;

![ca2b08367c3d911385e869b06f52344c.png][]

在这个例子里，我们**用 limit 100 让优化器意识到，使用 b 索引代价是很高的。其实是我们根据数据特征诱导了一下优化器，也不具备通用性。**

第三种方法是，**在有些场景下，我们可以新建一个更合适的索引，来提供给优化器做选择，或删掉误用的索引。**不过，在这个例子中，我没有找到通过新增索引来改变优化器行为的方法。这种情况其实比较少，尤其是经过 DBA 索引优化过的库，再碰到这个 bug，找到一个更合适的索引一般比较难。如果我说还有一个方法是删掉索引 b，你可能会觉得好笑。但实际上我碰到过两次这样的例子，最终是 DBA 跟业务开发沟通后，发现这个优化器错误选择的索引其实根本没有必要存在，于是就删掉了这个索引，优化器也就重新选择到了正确的索引。

#### 小结 ####

今天我们一起聊了聊索引统计的更新机制，并提到了优化器存在选错索引的可能性。**对于由于索引统计信息不准确导致的问题，你可以用 analyze table 来解决。而对于其他优化器误判的情况，你可以在应用端用 force index 来强行指定索引，也可以通过修改语句来引导优化器，还可以通过增加或者删除索引来绕过这个问题。**你可能会说，今天这篇文章后面的几个例子，怎么都没有展开说明其原理。我要告诉你的是，今天的话题，我们面对的是 MySQL 的 bug，每一个展开都必须深入到一行行代码去量化，实在不是我们在这里应该做的事情。

#### 思考题 ####

前面我们在构造第一个例子的过程中，通过 session A 的配合，让 session B 删除数据后又重新插入了一遍数据，然后就发现 explain 结果中，rows 字段从 10001 变成 37000 多。而如果没有 session A 的配合，只是单独执行 delete from t 、call idata()、explain 这三句话，会看到 rows 字段其实还是 10000 左右。你可以自己验证一下这个结果。这是什么原因呢？也请你分析一下吧。

**答案：**delete 语句删掉了所有的数据，然后再通过 call idata() 插入了 10 万行数据，看上去是覆盖了原来的 10 万行。但是，**session A 开启了事务并没有提交，所以之前插入的 10 万行数据是不能删除的。这样，之前的数据每一行数据都有两个版本，旧版本是 delete 之前的数据，新版本是标记为 deleted 的数据。这样，索引 a 上的数据其实就有两份。**然后你会说，不对啊，主键上的数据也不能删，那没有使用 force index 的语句，使用 explain 命令看到的扫描行数为什么还是 100000 左右？（潜台词，如果这个也翻倍，也许优化器还会认为选字段 a 作为索引更合适）是的，不过这个是主键，主键是直接按照表的行数来估计的。而表的行数，优化器直接用的是 show table status 的值。这个值的计算方法，我会在后面有文章为你详细讲解。

![61f5706a9f7a1e4722365eeb62143ff5.png][]

### 2.5 11 |13’| 怎么给字符串字段加索引？ ###

**内容来源：**[11 | 怎么给字符串字段加索引？-极客时间][11 _ _-]

现在，几乎所有的系统都支持邮箱登录，如何在邮箱这样的字段上建立合理的索引，是我们今天要讨论的问题。假设，你现在维护一个支持邮箱登录的系统，用户表是这么定义的：

mysql> create table SUser(
     ID bigint unsigned primary key,
     email varchar(64), 
     ... 
     )engine=innodb;

由于要使用邮箱登录，所以业务代码中一定会出现类似于这样的语句：

mysql> select f1, f2 from SUser where email='xxx';

从第 4 和第 5 篇讲解索引的文章中，我们可以知道，如果 email 这个字段上没有索引，那么这个语句就只能做全表扫描。同时，**MySQL 是支持前缀索引的，也就是说，你可以定义字符串的一部分作为索引。默认地，如果你创建索引的语句不指定前缀长度，那么索引就会包含整个字符串。**比如，这两个在 email 字段上创建索引的语句：

mysql> alter table SUser add index index1(email);
     或
     mysql> alter table SUser add index index2(email(6));

第一个语句创建的 index1 索引里面，包含了每个记录的整个字符串；而第二个语句创建的 index2 索引里面，对于每个记录都是只取前 6 个字节。那么，这两种不同的定义在数据结构和存储上有什么区别呢？如图 2 和 3 所示，就是这两个索引的示意图:

![a62ba2e8116a28a4927879830898dd1c.jpeg][]

![dec46a89917c762bcc48ecc8319ed424.jpeg][]

从图中你可以看到，由于 email(6) 这个索引结构中每个邮箱字段都只取前 6 个字节（即：zhangs），所以**占用的空间会更小，这就是使用前缀索引的优势。但，这同时带来的损失是，可能会增加额外的记录扫描次数**。接下来，我们再看看下面这个语句，在这两个索引定义下分别是怎么执行的。

select id,name,email from SUser where email='zhangssxyz@xxx.com';

**如果使用的是 index1（即 email 整个字符串的索引结构），执行顺序是这样的：**

1.  从 index1 索引树找到满足索引值是’[zhangssxyz@xxx.com][zhangssxyz_xxx.com]’的这条记录，取得 ID2 的值；
2.  到主键上查到主键值是 ID2 的行，判断 email 的值是正确的，将这行记录加入结果集；
3.  取 index1 索引树上刚刚查到的位置的下一条记录，发现已经不满足 email='[zhangssxyz@xxx.com][zhangssxyz_xxx.com]’的条件了，循环结束。

这个过程中，只需要回主键索引取一次数据，所以系统认为只扫描了一行。

**如果使用的是 index2（即 email(6) 索引结构），执行顺序是这样的：**

1.  从 index2 索引树找到满足索引值是’zhangs’的记录，找到的第一个是 ID1；
2.  到主键上查到主键值是 ID1 的行，判断出 email 的值不是’[zhangssxyz@xxx.com][zhangssxyz_xxx.com]’，这行记录丢弃；
3.  取 index2 上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，取出 ID2，再到 ID 索引上取整行然后判断，这次值对了，将这行记录加入结果集；
4.  重复上一步，直到在 idxe2 上取到的值不是’zhangs’时，循环结束。

在这个过程中，要回主键索引取 4 次数据，也就是扫描了 4 行。

通过这个对比，你很容易就可以发现，**使用前缀索引后，可能会导致查询语句读数据的次数变多**。但是，对于这个查询语句来说，如果你定义的 index2 不是 email(6) 而是 email(7），也就是说取 email 字段的前 7 个字节来构建索引的话，即满足前缀’zhangss’的记录只有一个，也能够直接查到 ID2，只扫描一行就结束了。也就是说**使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本。**

于是，你就有个问题：当要给字符串创建前缀索引时，有什么方法能够确定我应该使用多长的前缀呢？**实际上，我们在建立索引时关注的是区分度，区分度越高越好。因为区分度越高，意味着重复的键值越少。**因此，我们可以通过统计索引上有多少个不同的值来判断要使用多长的前缀。首先，你可以使用下面这个语句，算出这个列上有多少个不同的值：

mysql> select count(distinct email) as L from SUser;

然后，依次选取不同长度的前缀来看这个值，比如我们要看一下 4~7 个字节的前缀索引，可以用这个语句：

mysql> 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 SUser;

当然，**使用前缀索引很可能会损失区分度，所以你需要预先设定一个可以接受的损失比例，比如 5%。然后，在返回的 L4~L7 中，找出不小于 L \* 95% 的值，假设这里 L6、L7 都满足，你就可以选择前缀长度为 6**。

#### 前缀索引对覆盖索引的影响 ####

前面我们说了使用前缀索引可能会增加扫描行数，这会影响到性能。其实，前缀索引的影响不止如此，我们再看一下另外一个场景。你先来看看这个 SQL 语句：

select id,email from SUser where email='zhangssxyz@xxx.com';

与前面例子中的 SQL 语句

select id,name,email from SUser where email='zhangssxyz@xxx.com';

相比，这个语句只要求返回 id 和 email 字段。所以，如果使用 index1（即 email 整个字符串的索引结构）的话，可以利用覆盖索引，从 index1 查到结果后直接就返回了，不需要回到 ID 索引再去查一次。而如果使用 index2（即 email(6) 索引结构）的话，就不得不回到 ID 索引再去判断 email 字段的值。即使你将 index2 的定义修改为 email(18) 的前缀索引，这时候虽然 index2 已经包含了所有的信息，但 InnoDB 还是要回到 id 索引再查一下，因为系统并不确定前缀索引的定义是否截断了完整信息。也就是说，**使用前缀索引就用不上覆盖索引对查询性能的优化了，这也是你在选择是否使用前缀索引时需要考虑的一个因素**。

#### 其他方式 ####

对于类似于邮箱这样的字段来说，使用前缀索引的效果可能还不错。但是，遇到前缀的区分度不够好的情况时，我们要怎么办呢？比如，我们国家的身份证号，一共 18 位，其中前 6 位是地址码，所以同一个县的人的身份证号前 6 位一般会是相同的。假设你维护的数据库是一个市的公民信息系统，这时候如果对身份证号做长度为 6 的前缀索引的话，这个索引的区分度就非常低了。按照我们前面说的方法，可能你需要创建长度为 12 以上的前缀索引，才能够满足区分度要求。但是，**索引选取的越长，占用的磁盘空间就越大，相同的数据页能放下的索引值就越少，搜索的效率也就会越低**。

那么，如果我们能够确定业务需求里面只有按照身份证进行等值查询的需求，还有没有别的处理方法呢？这种方法，既可以占用更小的空间，也能达到相同的查询效率。答案是，有的。

**第一种方式是使用倒序存储。**如果你存储身份证号的时候把它倒过来存，每次查询的时候，你可以这么写：

mysql> select field_list from t where id_card = reverse('input_id_card_string');

由于身份证号的最后 6 位没有地址码这样的重复逻辑，所以最后这 6 位很可能就提供了足够的区分度。当然了，实践中你不要忘记使用 count(distinct) 方法去做个验证。

**第二种方式是使用 hash 字段。**你可以在表上再创建一个整数字段，来保存身份证的校验码，同时在这个字段上创建索引。

mysql> alter table t add id_card_crc int unsigned, add index(id_card_crc);

**然后每次插入新记录的时候，都同时用 crc32() 这个函数得到校验码填到这个新字段。由于校验码可能存在冲突，也就是说两个不同的身份证号通过 crc32() 函数得到的结果可能是相同的，所以你的查询语句 where 部分要判断 id\_card 的值是否精确相同。**

mysql> select field_list from t where id_card_crc=crc32('input_id_card_string') and id_card='input_id_card_string'

这样，索引的长度变成了 4 个字节，比原来小了很多。接下来，我们再一起看看**使用倒序存储和使用 hash 字段这两种方法的异同点。**

**首先，它们的相同点是，都不支持范围查询。倒序存储的字段上创建的索引是按照倒序字符串的方式排序的，已经没有办法利用索引方式查出身份证号码在\[ID\_X, ID\_Y\]的所有市民了。同样地，hash 字段的方式也只能支持等值查询。**

**它们的区别，主要体现在以下三个方面：**

1.  从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。当然，倒序存储方式使用 4 个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个 hash 字段也差不多抵消了。
2.  在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。如果只从这两个函数的计算复杂度来看的话，reverse 函数额外消耗的 CPU 资源会更小些。
3.  从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。

#### 小结 ####

在今天这篇文章中，我跟你聊了聊字符串字段创建索引的场景。我们来回顾一下，你可以使用的方式有：

1.  直接创建完整索引，这样可能比较占用空间；
2.  创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使用覆盖索引；
3.  倒序存储，再创建前缀索引，用于绕过字符串本身前缀的区分度不够的问题；
4.  创建 hash 字段索引，查询性能稳定，有额外的存储和计算消耗，跟第三种方式一样，都不支持范围扫描。

在实际应用中，你要根据业务字段的特点选择使用哪种方式。

#### 思考题 ####

如果你在维护一个学校的学生信息数据库，学生登录名的统一格式是”学号 @gmail.com", 而学号的规则是：十五位的数字，其中前三位是所在城市编号、第四到第六位是学校编号、第七位到第十位是入学年份、最后五位是顺序编号。系统登录的时候都需要学生输入登录名和密码，验证正确后才能继续使用系统。就只考虑登录验证这个行为的话，你会怎么设计这个登录名的索引呢？

**答案：**由于这个学号的规则，无论是正向还是反向的前缀索引，重复度都比较高。因为维护的只是一个学校的，因此前面 6 位（其中，前三位是所在城市编号、第四到第六位是学校编号）其实是固定的，邮箱后缀都是 @gamil.com，因此可以只存入学年份加顺序编号，它们的长度是 9 位。

而其实在此基础上，可以用数字类型来存这 9 位数字。比如 201100001，这样只需要占 4 个字节。其实这个就是一种 hash，只是它用了最简单的转换规则：字符串转数字的规则，而刚好我们设定的这个背景，可以保证这个转换后结果的唯一性。

### 2.6 15 |21’| 答疑文章（一）：日志和索引相关问题 ###

**内容来源：**[15 | 答疑文章（一）：日志和索引相关问题-极客时间][15 _ _-]

#### 日志相关问题 ####

我在第 2 篇文章《日志系统：一条 SQL 更新语句是如何执行的？》中，和你讲到 binlog（归档日志）和 redo log（重做日志）配合崩溃恢复的时候，用的是反证法，说明了如果没有两阶段提交，会导致 MySQL 出现主备数据不一致等问题。在这篇文章下面，很多同学在问，在两阶段提交的不同瞬间，MySQL 如果发生异常重启，是怎么保证数据完整性的？现在，我们就从这个问题开始吧。我再放一次两阶段提交的图，方便你学习下面的内容。

![faaf08c531be9b2651271a098cc8615d.jpeg][]

这里，我要先和你解释一个误会式的问题。有同学在评论区问到，这个图不是一个 update 语句的执行流程吗，怎么还会调用 commit 语句？他产生这个疑问的原因，是把两个“commit”的概念混淆了：

*  他说的“commit 语句”，是指 MySQL 语法中，用于提交一个事务的命令。一般跟 begin/start transaction 配对使用。
 *  而我们图中用到的这个“commit 步骤”，指的是事务提交过程中的一个小步骤，也是最后一步。当这个步骤执行完成后，这个事务就提交完成了。
 *  “commit 语句”执行的时候，会包含“commit 步骤”。

而我们这个例子里面，没有显式地开启事务，因此这个 update 语句自己就是一个事务，在执行完成后，提交事务时，就会用到这个“commit 步骤“。

接下来，我们就一起分析一下在两阶段提交的不同时刻，MySQL 异常重启会出现什么现象。如果在图中时刻 A 的地方，也就是写入 redo log 处于 prepare 阶段之后、写 binlog 之前，发生了崩溃（crash），由于此时 binlog 还没写，redo log 也还没提交，所以崩溃恢复的时候，这个事务会回滚。这时候，binlog 还没写，所以也不会传到备库。到这里，大家都可以理解。大家出现问题的地方，主要集中在时刻 B，也就是 binlog 写完，redo log 还没 commit 前发生 crash，那崩溃恢复的时候 MySQL 会怎么处理？我们先来看一下崩溃恢复时的判断规则：

*  如果 redo log 里面的事务是完整的，也就是已经有了 commit 标识，则直接提交；
 *  如果 redo log 里面的事务只有完整的 prepare，则判断对应的事务 binlog 是否存在并完整：
    
     *  a. 如果是，则提交事务；
     *  b. 否则，回滚事务。

这里，时刻 B 发生 crash 对应的就是 2(a) 的情况，崩溃恢复过程中事务会被提交。现在，我们继续延展一下这个问题。

#### 追问 1：MySQL 怎么知道 binlog 是完整的? ####

回答：**一个事务的 binlog 是有完整格式的：**

*  **statement 格式的 binlog，最后会有 COMMIT；**
 *  **row 格式的 binlog，最后会有一个 XID event。**

**另外，在 MySQL 5.6.2 版本以后，还引入了 binlog-checksum 参数，用来验证 binlog 内容的正确性。对于 binlog 日志，由于磁盘原因，可能会在日志中间出错的情况，MySQL 可以通过校验 checksum 的结果来发现。所以，MySQL 还是有办法验证事务 binlog 的完整性的。**

#### 追问 2：redo log 和 binlog 是怎么关联起来的? ####

回答：它们有一个共同的数据字段，叫 XID。崩溃恢复的时候，会按顺序扫描 redo log：

*  如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
 *  如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。

#### 追问 3：处于 prepare 阶段的 redo log 加上完整 binlog，重启就能恢复，MySQL 为什么要这么设计? ####

回答：其实，这个问题还是跟我们在反证法中说到的数据与备份的一致性有关。在时刻 B，也就是 binlog 写完以后 MySQL 发生崩溃，这时候 binlog 已经写入了，之后就会被从库（或者用这个 binlog 恢复出来的库）使用。所以，在主库上也要提交这个事务。采用这个策略，主库和备库的数据就保证了一致性。

#### 追问 4：如果这样的话，为什么还要两阶段提交呢？干脆先 redo log 写完，再写 binlog。崩溃恢复的时候，必须得两个日志都完整才可以。是不是一样的逻辑？ ####

回答：其实，两阶段提交是经典的分布式系统问题，并不是 MySQL 独有的。如果必须要举一个场景，来说明这么做的必要性的话，那就是事务的持久性问题。对于 InnoDB 引擎来说，如果 redo log 提交完成了，事务就不能回滚（如果这还允许回滚，就可能覆盖掉别的事务的更新）。而如果 redo log 直接提交，然后 binlog 写入的时候失败，InnoDB 又回滚不了，数据和 binlog 日志又不一致了。两阶段提交就是为了给所有人一个机会，当每个人都说“我 ok”的时候，再一起提交。

#### 追问 5：不引入两个日志，也就没有两阶段提交的必要了。只用 binlog 来支持崩溃恢复，又能支持归档，不就可以了？ ####

回答：这位同学的意思是，只保留 binlog，然后可以把提交流程改成这样：… -> “数据更新到内存” -> “写 binlog” -> “提交事务”，是不是也可以提供崩溃恢复的能力？答案是不可以。如果说历史原因的话，那就是 **InnoDB 并不是 MySQL 的原生存储引擎。MySQL 的原生引擎是 MyISAM，设计之初就有没有支持崩溃恢复。InnoDB 在作为 MySQL 的插件加入 MySQL 引擎家族之前，就已经是一个提供了崩溃恢复和事务支持的引擎了。InnoDB 接入了 MySQL 后，发现既然 binlog 没有崩溃恢复的能力，那就用 InnoDB 原有的 redo log 好了。**而如果说实现上的原因的话，就有很多了。就按照问题中说的，只用 binlog 来实现崩溃恢复的流程，我画了一张示意图，这里就没有 redo log 了。

![67bfd481728623dce711fbe607932b60.jpeg][]

这样的流程下，binlog 还是不能支持崩溃恢复的。我说一个不支持的点吧：binlog 没有能力恢复“数据页”。如果在图中标的位置，也就是 binlog2 写完了，但是整个事务还没有 commit 的时候，MySQL 发生了 crash。重启后，引擎内部事务 2 会回滚，然后应用 binlog2 可以补回来；但是对于事务 1 来说，系统已经认为提交完成了，不会再应用一次 binlog1。但是，InnoDB 引擎使用的是 WAL 技术，执行事务的时候，写完内存和日志，事务就算完成了。如果之后崩溃，要依赖于日志来恢复数据页。也就是说在图中这个位置发生崩溃的话，事务 1 也是可能丢失了的，而且是数据页级的丢失。此时，binlog 里面并没有记录数据页的更新细节，是补不回来的。你如果要说，那我优化一下 binlog 的内容，让它来记录数据页的更改可以吗？但，这其实就是又做了一个 redo log 出来。所以，至少现在的 binlog 能力，还不能支持崩溃恢复。

#### 追问 6：那能不能反过来，只用 redo log，不要 binlog？ ####

回答：如果只从崩溃恢复的角度来讲是可以的。你可以把 binlog 关掉，这样就没有两阶段提交了，但系统依然是 crash-safe 的。但是，如果你了解一下业界各个公司的使用场景的话，就会发现在正式的生产库上，binlog 都是开着的。**因为 binlog 有着 redo log 无法替代的功能。一个是归档。redo log 是循环写，写到末尾是要回到开头继续写的。这样历史日志没法保留，redo log 也就起不到归档的作用。一个就是 MySQL 系统依赖于 binlog。binlog 作为 MySQL 一开始就有的功能，被用在了很多地方。其中，MySQL 系统高可用的基础，就是 binlog 复制。还有很多公司有异构系统（比如一些数据分析系统），这些系统就靠消费 MySQL 的 binlog 来更新自己的数据。关掉 binlog 的话，这些下游系统就没法输入了。总之，由于现在包括 MySQL 高可用在内的很多系统机制都依赖于 binlog，所以“鸠占鹊巢”redo log 还做不到。**你看，发展生态是多么重要。

#### 追问 7：redo log 一般设置多大？ ####

回答：redo log 太小的话，会导致很快就被写满，然后不得不强行刷 redo log，这样 WAL 机制的能力就发挥不出来了。所以，如果是现在常见的几个 TB 的磁盘的话，就不要太小气了，直接将 redo log 设置为 4 个文件、每个文件 1GB 吧。

#### 追问 8：正常运行中的实例，数据写入后的最终落盘，是从 redo log 更新过来的还是从 buffer pool 更新过来的呢？ ####

回答：这个问题其实问得非常好。这里涉及到了，“redo log 里面到底是什么”的问题。实际上，redo log 并没有记录数据页的完整数据，所以它并没有能力自己去更新磁盘数据页，也就不存在“数据最终落盘，是由 redo log 更新过去”的情况。

*  如果是正常运行的实例的话，数据页被修改以后，跟磁盘的数据页不一致，称为脏页。最终数据落盘，就是把内存中的数据页写盘。这个过程，甚至与 redo log 毫无关系。
 *  在崩溃恢复场景中，InnoDB如果判断到一个数据页可能在崩溃恢复的时候丢失了更新，就会将它读到内存，然后让 redo log 更新内存内容。更新完成后，内存页变成脏页，就回到了第一种情况的状态。

#### 追问 9：redo log buffer 是什么？是先修改内存，还是先写 redo log 文件？ ####

回答：这两个问题可以一起回答。在一个事务的更新过程中，日志是要写多次的。比如下面这个事务：

begin;
     insert into t1 ...
     insert into t2 ...
     commit;

这个事务要往两个表中插入记录，插入数据的过程中，生成的日志都得先保存起来，但又不能在还没 commit 的时候就直接写到 redo log 文件里。所以，**redo log buffer 就是一块内存，用来先存 redo 日志的。**也就是说，在执行第一个 insert 的时候，数据的内存被修改了，redo log buffer 也写入了日志。但是，真正把日志写到 redo log 文件（文件名是 ib\_logfile+ 数字），是在执行 commit 语句的时候做的。（这里说的是事务执行过程中不会“主动去刷盘”，以减少不必要的 IO 消耗。但是可能会出现“被动写入磁盘”，比如内存不够、其他事务提交等情况。这个问题我们会在后面第 22 篇文章《MySQL 有哪些“饮鸩止渴”的提高性能的方法？》中再详细展开）。**单独执行一个更新语句的时候，InnoDB 会自己启动一个事务，在语句执行完成的时候提交。**过程跟上面是一样的，只不过是“压缩”到了一个语句里面完成。以上这些问题，就是把大家提过的关于 redo log 和 binlog 的问题串起来，做的一次集中回答。如果你还有问题，可以在评论区继续留言补充。

#### 业务设计问题 ####

接下来，我再和你分享 @ithunter 同学在第 8 篇文章《事务到底是隔离的还是不隔离的？》的评论区提到的跟索引相关的一个问题。我觉得这个问题挺有趣、也挺实用的，其他同学也可能会碰上这样的场景，在这里解答和分享一下。问题是这样的（我文字上稍微做了点修改，方便大家理解）：

业务上有这样的需求，A、B 两个用户，如果互相关注，则成为好友。设计上是有两张表，一个是 like 表，一个是 friend 表，like 表有 user\_id、liker\_id 两个字段，我设置为复合唯一索引即 uk\_user\_id\_liker\_id。语句执行逻辑是这样的：

以 A 关注 B 为例：第一步，先查询对方有没有关注自己（B 有没有关注 A）select \* from like where user\_id = B and liker\_id = A;

*  如果有，则成为好友insert into friend;

*  没有，则只是单向关注关系insert into like;

但是如果 A、B 同时关注对方，会出现不会成为好友的情况。因为上面第 1 步，双方都没关注对方。第 1 步即使使用了排他锁也不行，因为记录不存在，行锁无法生效。请问这种情况，在 MySQL 锁层面有没有办法处理？

首先，我要先赞一下这样的提问方式。虽然极客时间现在的评论区还不能追加评论，但如果大家能够一次留言就把问题讲清楚的话，其实影响也不大。所以，我希望你在留言提问的时候，也能借鉴这种方式。接下来，我把 @ithunter 同学说的表模拟出来，方便我们讨论。

CREATE TABLE `like` (
       `id` int(11) NOT NULL AUTO_INCREMENT,
       `user_id` int(11) NOT NULL,
       `liker_id` int(11) NOT NULL,
       PRIMARY KEY (`id`),
       UNIQUE KEY `uk_user_id_liker_id` (`user_id`,`liker_id`)
     ) ENGINE=InnoDB;
     
     CREATE TABLE `friend` (
       `id` int(11) NOT NULL AUTO_INCREMENT,
       `friend_1_id` int(11) NOT NULL,
       `friend_2_id` int(11) NOT NULL,
       UNIQUE KEY `uk_friend` (`friend_1_id`,`friend_2_id`),
       PRIMARY KEY (`id`)
     ) ENGINE=InnoDB;

虽然这个题干中，并没有说到 friend 表的索引结构。但我猜测 friend\_1\_id 和 friend\_2\_id 也有索引，为便于描述，我给加上唯一索引。顺便说明一下，“like”是关键字，我一般不建议使用关键字作为库名、表名、字段名或索引名。我把他的疑问翻译一下，在并发场景下，同时有两个人，设置为关注对方，就可能导致无法成功加为朋友关系。现在，我用你已经熟悉的时刻顺序表的形式，把这两个事务的执行语句列出来：

![3a2ee12e32dc2e13347aa3b3317247d1.png][]

由于一开始 A 和 B 之间没有关注关系，所以两个事务里面的 select 语句查出来的结果都是空。因此，session 1 的逻辑就是“既然 B 没有关注 A，那就只插入一个单向关注关系”。session 2 也同样是这个逻辑。这个结果对业务来说就是 bug 了。因为在业务设定里面，这两个逻辑都执行完成以后，是应该在 friend 表里面插入一行记录的。如提问里面说的，“第 1 步即使使用了排他锁也不行，因为记录不存在，行锁无法生效”。不过，我想到了另外一个方法，来解决这个问题。首先，要给“like”表增加一个字段，比如叫作 relation\_ship，并设为整型，取值 1、2、3。

*  值是 1 的时候，表示 user\_id 关注 liker\_id;
 *  值是 2 的时候，表示 liker\_id 关注 user\_id;
 *  值是 3 的时候，表示互相关注。然后，当 A 关注 B 的时候，逻辑改成如下所示的样子：

应用代码里面，比较 A 和 B 的大小，如果 A<B，就执行下面的逻辑：

mysql> begin; /*启动事务*/
     insert into `like`(user_id, liker_id, relation_ship) values(A, B, 1) on duplicate key update relation_ship=relation_ship | 1;
     select relation_ship from `like` where user_id=A and liker_id=B;
     /*代码中判断返回的 relation_ship，
       如果是1，事务结束，执行 commit
       如果是3，则执行下面这两个语句：
       */
     insert ignore into friend(friend_1_id, friend_2_id) values(A,B);
     commit;

如果 A>B，则执行下面的逻辑

mysql> begin; /*启动事务*/
     insert into `like`(user_id, liker_id, relation_ship) values(B, A, 2) on duplicate key update relation_ship=relation_ship | 2;
     select relation_ship from `like` where user_id=B and liker_id=A;
     /*代码中判断返回的 relation_ship，
       如果是2，事务结束，执行 commit
       如果是3，则执行下面这两个语句：
     */
     insert ignore into friend(friend_1_id, friend_2_id) values(B,A);
     commit;

这个设计里，让“like”表里的数据保证 user\_id < liker\_id，这样不论是 A 关注 B，还是 B 关注 A，在操作“like”表的时候，如果反向的关系已经存在，就会出现行锁冲突。然后，insert … on duplicate 语句，确保了在事务内部，执行了这个 SQL 语句后，就强行占住了这个行锁，之后的 select 判断 relation\_ship 这个逻辑时就确保了是在行锁保护下的读操作。操作符 “|” 是按位或，连同最后一句 insert 语句里的 ignore，是为了保证重复调用时的幂等性。这样，即使在双方“同时”执行关注操作，最终数据库里的结果，也是 like 表里面有一条关于 A 和 B 的记录，而且 relation\_ship 的值是 3， 并且 friend 表里面也有了 A 和 B 的这条记录。不知道你会不会吐槽：之前明明还说尽量不要使用唯一索引，结果这个例子一上来我就创建了两个。这里我要再和你说明一下，之前文章我们讨论的，是在“业务开发保证不会插入重复记录”的情况下，着重要解决性能问题的时候，才建议尽量使用普通索引。而像这个例子里，按照这个设计，业务根本就是保证“我一定会插入重复数据，数据库一定要要有唯一性约束”，这时就没啥好说的了，唯一索引建起来吧。

#### 小结 ####

这是专栏的第一篇答疑文章。我针对前 14 篇文章，大家在评论区中的留言，从中摘取了关于日志和索引的相关问题，串成了今天这篇文章。这里我也要再和你说一声，有些我答应在答疑文章中进行扩展的话题，今天这篇文章没来得及扩展，后续我会再找机会为你解答。所以，篇幅所限，评论区见吧。

#### 问题 ####

我们创建了一个简单的表 t，并插入一行，然后对这一行做修改。

mysql> CREATE TABLE `t` (
     `id` int(11) NOT NULL primary key auto_increment,
     `a` int(11) DEFAULT NULL
     ) ENGINE=InnoDB;
     insert into t values(1,2);

这时候，表 t 里有唯一的一行数据 (1,2)。假设，我现在要执行：

mysql> update t set a=2 where id=1;

你会看到这样的结果：

![0dda37bc56230fa8bac0320fc8c21e60.png][]

结果显示，匹配 (rows matched) 了一行，修改 (Changed) 了 0 行。

仅从现象上看，MySQL 内部在处理这个命令的时候，可以有以下三种选择：

*  更新都是先读后写的，MySQL 读出数据，发现 a 的值本来就是 2，不更新，直接返回，执行结束；
 *  MySQL 调用了 InnoDB 引擎提供的“修改为 (1,2)”这个接口，但是引擎发现值与原来相同，不更新，直接返回；
 *  InnoDB 认真执行了“把这个值修改成 (1,2)"这个操作，该加锁的加锁，该更新的更新。

你觉得实际情况会是以上哪种呢？你可否用构造实验的方式，来证明你的结论？进一步地，可以思考一下，MySQL 为什么要选择这种策略呢？

**答案：**当 MySQL 去更新一行，但是要修改的值跟原来的值是相同的，这时候 MySQL 会真的去执行一次修改吗？还是看到值相同就直接返回呢？这是第一次我们课后问题的三个选项都有同学选的，所以我要和你需要详细说明一下。

第一个选项是，MySQL 读出数据，发现值与原来相同，不更新，直接返回，执行结束。这里我们可以用一个锁实验来确认。假设，当前表 t 里的值是 (1,2)。

![49b427824450bb255c4d0f7db346c8da.png][]

session B 的 update 语句被 blocked 了，加锁这个动作是 InnoDB 才能做的，所以排除选项 1。

第二个选项是，MySQL 调用了 InnoDB 引擎提供的接口，但是引擎发现值与原来相同，不更新，直接返回。有没有这种可能呢？这里我用一个可见性实验来确认。

假设当前表里的值是 (1,2)。

![d1ff9ce61f89cde6af793b2d41453af9.png][]

session A 的第二个 select 语句是一致性读（快照读)，它是不能看见 session B 的更新的。现在它返回的是 (1,3)，表示它看见了某个新的版本，这个版本只能是 session A 自己的 update 语句做更新的时候生成。（如果你对这个逻辑有疑惑的话，可以回顾下第 8 篇文章《事务到底是隔离的还是不隔离的？》中的相关内容）

所以，我们上期思考题的答案应该是选项 3，即：InnoDB 认真执行了“把这个值修改成 (1,2)"这个操作，该加锁的加锁，该更新的更新。然后你会说，MySQL 怎么这么笨，就不会更新前判断一下值是不是相同吗？如果判断一下，不就不用浪费 InnoDB 操作，多去更新一次了？其实 MySQL 是确认了的。只是在这个语句里面，MySQL 认为读出来的值，只有一个确定的 (id=1), 而要写的是 (a=3)，只从这两个信息是看不出来“不需要修改”的。作为验证，你可以看一下下面这个例子。

![75d9649b6e07107c3174193deaf20fcf.png][]

**补充说明：**

上面我们的验证结果都是在 binlog\_format=statement 格式下进行的。

@didiren 补充了一个 case， 如果是 binlog\_format=row 并且 binlog\_row\_image=FULL 的时候，由于 MySQL 需要在 binlog 里面记录所有的字段，所以在读数据的时候就会把所有数据都读出来了。根据上面说的规则，“既然读了数据，就会判断”， 因此在这时候，select \* from t where id=1，结果就是“返回 (1,2)”。同理，如果是 binlog\_row\_image=NOBLOB, 会读出除 blob 外的所有字段，在我们这个例子里，结果还是“返回 (1,2)”。对应的代码如图 15 所示。这是 MySQL 5.6 版本引入的，在此之前我没有看过。所以，特此说明。

![a998712d5bbf9a70cca88194b52570b0.png][]

### 2.7 16 |17’| “order by”是怎么工作的？ ###

**内容来源：**[16 | “order by”是怎么工作的？-极客时间][16 _ _order by_-]

在你开发应用的时候，一定会经常碰到需要根据指定的字段排序来显示结果的需求。还是以我们前面举例用过的市民表为例，假设你要查询城市是“杭州”的所有人名字，并且按照姓名排序返回前 1000 个人的姓名、年龄。假设这个表的部分定义是这样的：

CREATE TABLE `t` (
       `id` int(11) NOT NULL,
       `city` varchar(16) NOT NULL,
       `name` varchar(16) NOT NULL,
       `age` int(11) NOT NULL,
       `addr` varchar(128) DEFAULT NULL,
       PRIMARY KEY (`id`),
       KEY `city` (`city`)
     ) ENGINE=InnoDB;

这时，你的 SQL 语句可以这么写：

select city,name,age from t where city='杭州' order by name limit 1000  ;

这个语句看上去逻辑很清晰，但是你了解它的执行流程吗？今天，我就和你聊聊这个语句是怎么执行的，以及有什么参数会影响执行的行为。

#### 全字段排序 ####

前面我们介绍过索引，所以你现在就很清楚了，为避免全表扫描，我们需要在 city 字段加上索引。在 city 字段上创建索引之后，我们用 explain 命令来看看这个语句的执行情况。

![60821d231085c73a8375411465755dc4.png][]

**Extra 这个字段中的“Using filesort”表示的就是需要排序，MySQL 会给每个线程分配一块内存用于排序，称为 sort\_buffer。**为了说明这个 SQL 查询语句的执行过程，我们先来看一下 city 这个索引的示意图:

![97205ebdb364a8cc46ec3889c649b2e6.png][]

从图中可以看到，满足 city='杭州’条件的行，是从 ID\_X 到 ID\_(X+N) 的这些记录。通常情况下，这个语句执行流程如下所示 ：

1.  初始化 sort\_buffer，确定放入 name、city、age 这三个字段；
2.  从索引 city 找到第一个满足 city='杭州’条件的主键 id，也就是图中的 ID\_X；
3.  到主键 id 索引取出整行，取 name、city、age 三个字段的值，存入 sort\_buffer 中；
4.  从索引 city 取下一个记录的主键 id；
5.  重复步骤 3、4 直到 city 的值不满足查询条件为止，对应的主键 id 也就是图中的 ID\_Y；
6.  对 sort\_buffer 中的数据按照字段 name 做快速排序；
7.  按照排序结果取前 1000 行返回给客户端。

我们暂且把这个排序过程，称为全字段排序，执行流程的示意图如下所示，下一篇文章中我们还会用到这个排序。

![4eed5ac063a428bef5bd765793021599.jpeg][]

**图中“按 name 排序”这个动作，可能在内存中完成，也可能需要使用外部排序，这取决于排序所需的内存和参数 sort\_buffer\_size。sort\_buffer\_size，就是 MySQL 为排序开辟的内存（sort\_buffer）的大小。如果要排序的数据量小于 sort\_buffer\_size，排序就在内存中完成。但如果排序数据量太大，内存放不下，则不得不利用磁盘临时文件辅助排序。**你可以用下面介绍的方法，来确定一个排序语句是否使用了临时文件。

/* 打开optimizer_trace，只对本线程有效 */
     SET optimizer_trace='enabled=on'; 
     
     /* @a保存Innodb_rows_read的初始值 */
     select VARIABLE_VALUE into @a from  performance_schema.session_status where variable_name = 'Innodb_rows_read';
     
     /* 执行语句 */
     select city, name,age from t where city='杭州' order by name limit 1000; 
     
     /* 查看 OPTIMIZER_TRACE 输出 */
     SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G
     
     /* @b保存Innodb_rows_read的当前值 */
     select VARIABLE_VALUE into @b from performance_schema.session_status where variable_name = 'Innodb_rows_read';
     
     /* 计算Innodb_rows_read差值 */
     select @b-@a;

这个方法是通过查看 OPTIMIZER\_TRACE 的结果来确认的，你可以从 number\_of\_tmp\_files 中看到是否使用了临时文件。

![1cfc8579749ec9d5557e954e5a668324.png][]

**number\_of\_tmp\_files 表示的是，排序过程中使用的临时文件数。**你一定奇怪，为什么需要 12 个文件？**内存放不下时，就需要使用外部排序，外部排序一般使用归并排序算法。**可以这么简单理解，**MySQL 将需要排序的数据分成 12 份，每一份单独排序后存在这些临时文件中。然后把这 12 个有序文件再合并成一个有序的大文件。如果 sort\_buffer\_size 超过了需要排序的数据量的大小，number\_of\_tmp\_files 就是 0，表示排序可以直接在内存中完成。否则就需要放在临时文件中排序。sort\_buffer\_size 越小，需要分成的份数越多，number\_of\_tmp\_files 的值就越大。**接下来，我再和你解释一下图 4 中其他两个值的意思。我们的示例表中有 4000 条满足 city='杭州’的记录，所以你可以看到 examined\_rows=4000，表示参与排序的行数是 4000 行。**sort\_mode 里面的 packed\_additional\_fields 的意思是，排序过程对字符串做了“紧凑”处理。**即使 name 字段的定义是 varchar(16)，在排序过程中还是要按照实际长度来分配空间的。

同时，**最后一个查询语句 select @b-@a 的返回结果是 4000，表示整个执行过程只扫描了 4000 行。这里需要注意的是，为了避免对结论造成干扰，我把 internal\_tmp\_disk\_storage\_engine 设置成 MyISAM。否则，select @b-@a 的结果会显示为 4001。这是因为查询 OPTIMIZER\_TRACE 这个表时，需要用到临时表，而 internal\_tmp\_disk\_storage\_engine 的默认值是 InnoDB。如果使用的是 InnoDB 引擎的话，把数据从临时表取出来的时候，会让 Innodb\_rows\_read 的值加 1。**

#### rowid 排序 ####

在上面这个算法过程里面，只对原表的数据读了一遍，剩下的操作都是在 sort\_buffer 和临时文件中执行的。但这个算法有一个问题，就是如果查询要返回的字段很多的话，那么 sort\_buffer 里面要放的字段数太多，这样内存里能够同时放下的行数很少，要分成很多个临时文件，排序的性能会很差。所以如果单行很大，这个方法效率不够好。那么，如果 MySQL 认为排序的单行长度太大会怎么做呢？接下来，我来修改一个参数，让 MySQL 采用另外一种算法。

SET max_length_for_sort_data = 16;

**max\_length\_for\_sort\_data，是 MySQL 中专门控制用于排序的行数据的长度的一个参数。它的意思是，如果单行的长度超过这个值，MySQL 就认为单行太大，要换一个算法。**city、name、age 这三个字段的定义总长度是 36，我把 max\_length\_for\_sort\_data 设置为 16，我们再来看看计算过程有什么改变。新的算法放入 sort\_buffer 的字段，只有要排序的列（即 name 字段）和主键 id。但这时，排序的结果就因为少了 city 和 age 字段的值，不能直接返回了，整个执行流程就变成如下所示的样子：

1.  初始化 sort\_buffer，确定放入两个字段，即 name 和 id；
2.  从索引 city 找到第一个满足 city='杭州’条件的主键 id，也就是图中的 ID\_X；
3.  到主键 id 索引取出整行，取 name、id 这两个字段，存入 sort\_buffer 中；
4.  从索引 city 取下一个记录的主键 id；
5.  重复步骤 3、4 直到不满足 city='杭州’条件为止，也就是图中的 ID\_Y；
6.  对 sort\_buffer 中的数据按照字段 name 进行排序；
7.  遍历排序结果，取前 1000 行，并按照 id 的值回到原表中取出 city、name 和 age 三个字段返回给客户端。

这个执行流程的示意图如下，我把它称为 rowid 排序。

![f1f72311c46b2a5510a8eaa4e468b09d.jpeg][]

对比图 3 的全字段排序流程图你会发现，rowid 排序多访问了一次表 t 的主键索引，就是步骤 7。需要说明的是，最后的“结果集”是一个逻辑概念，实际上 MySQL 服务端从排序后的 sort\_buffer 中依次取出 id，然后到原表查到 city、name 和 age 这三个字段的结果，不需要在服务端再耗费内存存储结果，是直接返回给客户端的。根据这个说明过程和图示，你可以想一下，这个时候执行 select @b-@a，结果会是多少呢？现在，我们就来看看结果有什么不同。首先，图中的 examined\_rows 的值还是 4000，表示用于排序的数据是 4000 行。但是 select @b-@a 这个语句的值变成 5000 了。因为这时候除了排序过程外，在排序完成后，还要根据 id 去原表取值。由于语句是 limit 1000，因此会多读 1000 行。

![52a1782288e97bccdd5cf06106192fb9.png][]

从 OPTIMIZER\_TRACE 的结果中，你还能看到另外两个信息也变了。

*  sort\_mode 变成了 ，表示参与排序的只有 name 和 id 这两个字段。
 *  number\_of\_tmp\_files 变成 10 了，是因为这时候参与排序的行数虽然仍然是 4000 行，但是每一行都变小了，因此需要排序的总数据量就变小了，需要的临时文件也相应地变少了。

#### 全字段排序 VS rowid 排序 ####

我们来分析一下，从这两个执行流程里，还能得出什么结论。**如果 MySQL 实在是担心排序内存太小，会影响排序效率，才会采用 rowid 排序算法，这样排序过程中一次可以排序更多行，但是需要再回到原表去取数据。如果 MySQL 认为内存足够大，会优先选择全字段排序，把需要的字段都放到 sort\_buffer 中，这样排序后就会直接从内存里面返回查询结果了，不用再回到原表去取数据。这也就体现了 MySQL 的一个设计思想：如果内存够，就要多利用内存，尽量减少磁盘访问。对于 InnoDB 表来说，rowid 排序会要求回表多造成磁盘读，因此不会被优先选择**。这个结论看上去有点废话的感觉，但是你要记住它，下一篇文章我们就会用到。看到这里，你就了解了，MySQL 做排序是一个成本比较高的操作。那么你会问，是不是所有的 order by 都需要排序操作呢？如果不排序就能得到正确的结果，那对系统的消耗会小很多，语句的执行时间也会变得更短。

其实，**并不是所有的 order by 语句，都需要排序操作的。**从上面分析的执行过程，我们可以看到，MySQL 之所以需要生成临时表，并且在临时表上做排序操作，其原因是原来的数据都是无序的。你可以设想下，如果能够保证从 city 这个索引上取出来的行，天然就是按照 name 递增排序的话，是不是就可以不用再排序了呢？确实是这样的。所以，我们可以在这个市民表上创建一个 city 和 name 的联合索引，对应的 SQL 语句是：

alter table t add index city_user(city, name);

作为与 city 索引的对比，我们来看看这个索引的示意图。

![e20177772447428efaad499cab6508d9.png][]

在这个索引里面，我们依然可以用树搜索的方式定位到第一个满足 city='杭州’的记录，并且额外确保了，接下来按顺序取“下一条记录”的遍历过程中，只要 city 的值是杭州，name 的值就一定是有序的。这样整个查询过程的流程就变成了：

1.  从索引 (city,name) 找到第一个满足 city='杭州’条件的主键 id；
2.  到主键 id 索引取出整行，取 name、city、age 三个字段的值，作为结果集的一部分直接返回；
3.  从索引 (city,name) 取下一个记录主键 id；
4.  重复步骤 2、3，直到查到第 1000 条记录，或者是不满足 city='杭州’条件时循环结束。

![9a426a52cb62ecfea2c6665e5b41aee6.jpeg][]

可以看到，这个查询过程不需要临时表，也不需要排序。接下来，我们用 explain 的结果来印证一下。

![2d0c96583ee23fb58583f3c6f03cdb60.png][]

从图中可以看到，**Extra 字段中没有 Using filesort 了，也就是不需要排序了**。而且由于 (city,name) 这个联合索引本身有序，所以这个查询也不用把 4000 行全都读一遍，只要找到满足条件的前 1000 条记录就可以退出了。也就是说，在我们这个例子里，只需要扫描 1000 次。既然说到这里了，我们再往前讨论，这个语句的执行流程有没有可能进一步简化呢？不知道你还记不记得，我在第 5 篇文章《 深入浅出索引（下）》中，和你介绍的覆盖索引。这里我们可以再稍微复习一下。**覆盖索引是指，索引上的信息足够满足查询请求，不需要再回到主键索引上去取数据。**按照覆盖索引的概念，我们可以再优化一下这个查询语句的执行流程。针对这个查询，我们可以创建一个 city、name 和 age 的联合索引，对应的 SQL 语句就是：

alter table t add index city_user_age(city, name, age);

这时，对于 city 字段的值相同的行来说，还是按照 name 字段的值递增排序的，此时的查询语句也就不再需要排序了。这样整个查询语句的执行流程就变成了：

1.  从索引 (city,name,age) 找到第一个满足 city='杭州’条件的记录，取出其中的 city、name 和 age 这三个字段的值，作为结果集的一部分直接返回；
2.  从索引 (city,name,age) 取下一个记录，同样取出这三个字段的值，作为结果集的一部分直接返回；
3.  重复执行步骤 2，直到查到第 1000 条记录，或者是不满足 city='杭州’条件时循环结束。

![5360b8ac2c4556bcb4cfd9b72db6993d.jpeg][]

然后，我们再来看看 explain 的结果:

![9b5edc236f3a3aef05f86b87ff6d5dec.png][]

可以看到，**Extra 字段里面多了“Using index”，表示的就是使用了覆盖索引，性能上会快很多。当然，这里并不是说要为了每个查询能用上覆盖索引，就要把语句中涉及的字段都建上联合索引，毕竟索引还是有维护代价的。这是一个需要权衡的决定。**

#### 小结 ####

今天这篇文章，我和你介绍了 MySQL 里面 order by 语句的几种算法流程。在开发系统的时候，你总是不可避免地会使用到 order by 语句。你心里要清楚每个语句的排序逻辑是怎么实现的，还要能够分析出在最坏情况下，每个语句的执行对系统资源的消耗，这样才能做到下笔如有神，不犯低级错误。

#### 思考题 ####

假设你的表里面已经有了 city\_name(city, name) 这个联合索引，然后你要查杭州和苏州两个城市中所有的市民的姓名，并且按名字排序，显示前 100 条记录。如果 SQL 查询语句是这么写的 ：

mysql> select * from t where city in ('杭州',"苏州") order by name limit 100;

那么，这个语句执行的时候会有排序过程吗，为什么？如果业务端代码由你来开发，需要实现一个在数据库端不需要排序的方案，你会怎么实现呢？进一步地，如果有分页需求，要显示第 101 页，也就是说语句最后要改成 “limit 10000,100”， 你的实现方法又会是什么呢？

**答案：**虽然有 (city,name) 联合索引，对于单个 city 内部，name 是递增的。但是由于这条 SQL 语句不是要单独地查一个 city 的值，而是同时查了"杭州"和" 苏州 "两个城市，因此所有满足条件的 name 就不是递增的了。也就是说，这条 SQL 语句需要排序。

那怎么避免排序呢？这里，我们要用到 (city,name) 联合索引的特性，把这一条语句拆成两条语句，执行流程如下：

1.  执行 select \* from t where city=“杭州” order by name limit 100; 这个语句是不需要排序的，客户端用一个长度为 100 的内存数组 A 保存结果。
2.  执行 select \* from t where city=“苏州” order by name limit 100; 用相同的方法，假设结果被存进了内存数组 B。
3.  现在 A 和 B 是两个有序数组，然后你可以用归并排序的思想，得到 name 最小的前 100 值，就是我们需要的结果了。

如果把这条 SQL 语句里“limit 100”改成“limit 10000,100”的话，处理方式其实也差不多，即：要把上面的两条语句改成写：

select * from t where city="杭州" order by name limit 10100;

和

select * from t where city="苏州" order by name limit 10100。

这时候数据量较大，可以同时起两个连接一行行读结果，用归并排序算法拿到这两个结果集里，按顺序取第 10001~10100 的 name 值，就是需要的结果了。当然这个方案有一个明显的损失，就是从数据库返回给客户端的数据量变大了。所以，如果数据的单行比较大的话，可以考虑把这两条 SQL 语句改成下面这种写法：

select id,name from t where city="杭州" order by name limit 10100;

和

select id,name from t where city="苏州" order by name limit 10100。

然后，再用归并排序的方法取得按 name 顺序第 10001~10100 的 name、id 的值，然后拿着这 100 个 id 到数据库中去查出所有记录。上面这些方法，需要你根据性能需求和开发的复杂度做出权衡。

### 2.8 18 |16’| 为什么这些SQL语句逻辑相同，性能却差异巨大？ ###

**内容来源：**[18 | 为什么这些SQL语句逻辑相同，性能却差异巨大？-极客时间][18 _ _SQL_-]

## 3. 事务相关【68’】 ##

### 3.1 03 |11’| 事务隔离：为什么你改了我还看不见？ ###

**内容来源：**[03 | 事务隔离：为什么你改了我还看不见？-极客时间][03 _ _-]

### 3.2 08 |19’| 事务到底是隔离的还是不隔离的？ ###

**内容来源：**[08 | 事务到底是隔离的还是不隔离的？-极客时间][08 _ _-]

### 3.3 20 |20’| 幻读是什么，幻读有什么问题？ ###

**内容来源：**[20 | 幻读是什么，幻读有什么问题？-极客时间][20 _ _-]

### 3.4 39 |18’| 自增主键为什么不是连续的？ ###

**内容来源：**[39 | 自增主键为什么不是连续的？-极客时间][39 _ _-]

## 4. 锁相关【85’】 ##

### 4.1 06 |13’| 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？ ###

**内容来源：**[06 | 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？-极客时间][06 _ _ _-]

### 4.2 07 |12’| 行锁功过：怎么减少行锁对性能的影响？ ###

**内容来源：**[07 | 行锁功过：怎么减少行锁对性能的影响？-极客时间][07 _ _-]

### 4.3 19 |13’| 为什么我只查一行的语句，也执行这么慢？ ###

**内容来源：**[19 | 为什么我只查一行的语句，也执行这么慢？-极客时间][19 _ _-]

### 4.4 21 |18’| 为什么我只改一行的语句，锁这么多？ ###

**内容来源：**[21 | 为什么我只改一行的语句，锁这么多？-极客时间][21 _ _-]

### 4.3 30 |16’| 答疑文章（二）：用动态的观点看加锁 ###

**内容来源：**[30 | 答疑文章（二）：用动态的观点看加锁-极客时间][30 _ _-]

###  ###

### 4.4 40 |13’| insert语句的锁为什么这么多？ ###

**内容来源：**[40 | insert语句的锁为什么这么多？-极客时间][40 _ insert_-]

## 5. 日志与主备相关【183’】 ##

### 5.1 02 |15’| 日志系统：一条SQL更新语句是如何执行的？ ###

**内容来源：**[02 | 日志系统：一条SQL更新语句是如何执行的？-极客时间][02 _ _SQL_-]

### 5.2 12 |16’| 为什么我的MySQL会“抖”一下？ ###

**内容来源：**[12 | 为什么我的MySQL会“抖”一下？-极客时间][12 _ _MySQL_-]

### 5.3 23 |17’| MySQL是怎么保证数据不丢的？ ###

**内容来源：**[23 | MySQL是怎么保证数据不丢的？-极客时间][23 _ MySQL_-]

### 5.4 24 |20’| MySQL是怎么保证主备一致的？ ###

**内容来源：**[24 | MySQL是怎么保证主备一致的？-极客时间][24 _ MySQL_-]

### 5.5 25 |18’| MySQL是怎么保证高可用的？ ###

**内容来源：**[25 | MySQL是怎么保证高可用的？-极客时间][25 _ MySQL_-]

### 5.6 26 |24’| 备库为什么会延迟好几个小时？ ###

**内容来源：**[26 | 备库为什么会延迟好几个小时？-极客时间][26 _ _-]

### 5.7 27 |20’| 主库出问题了，从库怎么办？ ###

**内容来源：**[27 | 主库出问题了，从库怎么办？-极客时间][27 _ _-]

### 5.8 28 |22’| 读写分离有哪些坑？ ###

**内容来源：**[28 | 读写分离有哪些坑？-极客时间][28 _ _-]

### 5.9 29 |15’| 如何判断一个数据库是不是出问题了？ ###

**内容来源：**[29 | 如何判断一个数据库是不是出问题了？-极客时间][29 _ _-]

### 5.10 31 |16’| 误删数据后除了跑路，还能怎么办？ ###

**内容来源：**[31 | 误删数据后除了跑路，还能怎么办？-极客时间][31 _ _-]

## 6. 临时表相关【95’】 ##

### 6.1 17 |17’| 如何正确地显示随机消息？ ###

**内容来源：**[17 | 如何正确地显示随机消息？-极客时间][17 _ _-]

### 6.2 34 |17’| 到底可不可以使用join？ ###

**内容来源：**[34 | 到底可不可以使用join？-极客时间][34 _ _join_-]

### 6.3 35 |17’| join语句怎么优化？ ###

**内容来源：**[35 | join语句怎么优化？-极客时间][35 _ join_-]

### 6.4 36 |17’| 为什么临时表可以重名？ ###

**内容来源：**[36 | 为什么临时表可以重名？-极客时间][36 _ _-]

### 6.5 37 |14’| 什么时候会使用内部临时表？ ###

**内容来源：**[37 | 什么时候会使用内部临时表？-极客时间][37 _ _-]

### 6.6 43 |13’| 要不要使用分区表？ ###

**内容来源：**[43 | 要不要使用分区表？-极客时间][43 _ _-]

## 7. 实用性归类【151’】 ##

### 7.1 13 |15’| 为什么表数据删掉一半，表文件大小不变？ ###

**内容来源：**[13 | 为什么表数据删掉一半，表文件大小不变？-极客时间][13 _ _-]

### 7.2 14 |16’| count(\* )这么慢，我该怎么办？ ###

**内容来源：**[14 | count(\*)这么慢，我该怎么办？-极客时间][14 _ count_-]

### 7.3 22 |15’| MySQL有哪些“饮鸩止渴”提高性能的方法？ ###

**内容来源：**[22 | MySQL有哪些“饮鸩止渴”提高性能的方法？-极客时间][22 _ MySQL_-]

### 7.4 32 |14’| 为什么还有kill不掉的语句？ ###

**内容来源：**[32 | 为什么还有kill不掉的语句？-极客时间][32 _ _kill_-]

### 7.5 33 |15’| 我查这么多数据，会不会把数据库内存打爆？ ###

**内容来源：**[33 | 我查这么多数据，会不会把数据库内存打爆？-极客时间][33 _ _-]

### 7.6 38 |14’| 都说InnoDB好，那还要不要使用Memory引擎？ ###

**内容来源：**[38 | 都说InnoDB好，那还要不要使用Memory引擎？-极客时间][38 _ _InnoDB_Memory_-]

### 7.7 41 |14’| 怎么最快地复制一张表？ ###

**内容来源：**[41 | 怎么最快地复制一张表？-极客时间][41 _ _-]

### 7.8 42 |13’| grant之后要跟着flush privileges吗？ ###

**内容来源：**[42 | grant之后要跟着flush privileges吗？-极客时间][42 _ grant_flush privileges_-]

### 7.9 44 |17’| 答疑文章（三）：说一说这些好问题 ###

**内容来源：**[44 | 答疑文章（三）：说一说这些好问题-极客时间][44 _ _-]

### 7.10 45 |18’| 自增id用完怎么办？ ###

**内容来源：**[45 | 自增id用完怎么办？-极客时间][45 _ _id_-]

[_ _MySQL-]: https://time.geekbang.org/column/article/67888
[d8ddde2b693443b591ab1b1f622e7ff8.png]: https://img-blog.csdnimg.cn/d8ddde2b693443b591ab1b1f622e7ff8.png
[01 _ _SQL_-]: https://time.geekbang.org/column/article/68319
[7c9cb1fb3fd3461884bd464107da95d1.png]: https://img-blog.csdnimg.cn/7c9cb1fb3fd3461884bd464107da95d1.png
[0524ecaec7464a1aaf4b6577bb39e086.png]: https://img-blog.csdnimg.cn/0524ecaec7464a1aaf4b6577bb39e086.png
[96210782f126492f80cd53ea66e768ce.png]: https://img-blog.csdnimg.cn/96210782f126492f80cd53ea66e768ce.png
[04 _ _-]: https://time.geekbang.org/column/article/69236
[9bc0c700b9a6895a1a2acfcfa1b025b0.png]: https://img-blog.csdnimg.cn/img_convert/9bc0c700b9a6895a1a2acfcfa1b025b0.png
[9e9c0b76c8d7504f8beb79a41180c450.png]: https://img-blog.csdnimg.cn/img_convert/9e9c0b76c8d7504f8beb79a41180c450.png
[853bc884d11a664619e503c93ce1662c.png]: https://img-blog.csdnimg.cn/img_convert/853bc884d11a664619e503c93ce1662c.png
[e3030fc34806ea235355fd23a72c4c1c.png]: https://img-blog.csdnimg.cn/img_convert/e3030fc34806ea235355fd23a72c4c1c.png
[05 _ _-]: https://time.geekbang.org/column/article/69636
[5dd3f5d240b4a6a7643187ff77305226.png]: https://img-blog.csdnimg.cn/img_convert/5dd3f5d240b4a6a7643187ff77305226.png
[163c2c0e095791d126f96155e52c1274.jpeg]: https://img-blog.csdnimg.cn/img_convert/163c2c0e095791d126f96155e52c1274.jpeg
[7395f966b087ea31e404226a71ebe48e.jpeg]: https://img-blog.csdnimg.cn/img_convert/7395f966b087ea31e404226a71ebe48e.jpeg
[a217eb877c633d600289a7133425dbab.jpeg]: https://img-blog.csdnimg.cn/img_convert/a217eb877c633d600289a7133425dbab.jpeg
[09 _ _-]: https://time.geekbang.org/column/article/70848
[39ad8559472e375c4fe07d4313222637.png]: https://img-blog.csdnimg.cn/img_convert/39ad8559472e375c4fe07d4313222637.png
[cf322c58852d774e4d3c986a59f7203a.png]: https://img-blog.csdnimg.cn/img_convert/cf322c58852d774e4d3c986a59f7203a.png
[278103b8e5bd5ab43139250a3e2dbc27.png]: https://img-blog.csdnimg.cn/img_convert/278103b8e5bd5ab43139250a3e2dbc27.png
[10 _ MySQL_-]: https://time.geekbang.org/column/article/71173
[c5ef904458392c2fb9fe0bfc78a711d9.png]: https://img-blog.csdnimg.cn/img_convert/c5ef904458392c2fb9fe0bfc78a711d9.png
[ec6ce7e9b533624657f85d60c1b199b0.png]: https://img-blog.csdnimg.cn/img_convert/ec6ce7e9b533624657f85d60c1b199b0.png
[859353eaaa9abdacdad74b72e86ec7e8.png]: https://img-blog.csdnimg.cn/img_convert/859353eaaa9abdacdad74b72e86ec7e8.png
[8f9ecd87a69f207eddf657b45c89be89.png]: https://img-blog.csdnimg.cn/img_convert/8f9ecd87a69f207eddf657b45c89be89.png
[8d6f933ed9fa647090b2c5e2c36388e3.png]: https://img-blog.csdnimg.cn/img_convert/8d6f933ed9fa647090b2c5e2c36388e3.png
[443ca71bb3c35c7a0723064c832ba69d.png]: https://img-blog.csdnimg.cn/img_convert/443ca71bb3c35c7a0723064c832ba69d.png
[28634bc5ed03623296363b7f5fe44c19.png]: https://img-blog.csdnimg.cn/img_convert/28634bc5ed03623296363b7f5fe44c19.png
[f8dc05dc6c9d56d6b92e27aeacc571ab.png]: https://img-blog.csdnimg.cn/img_convert/f8dc05dc6c9d56d6b92e27aeacc571ab.png
[6fcdc6ad7d8921cd2b31cb591ec80cbe.png]: https://img-blog.csdnimg.cn/img_convert/6fcdc6ad7d8921cd2b31cb591ec80cbe.png
[4651f9bb4c98907ff75e19340be8de56.png]: https://img-blog.csdnimg.cn/img_convert/4651f9bb4c98907ff75e19340be8de56.png
[ca2b08367c3d911385e869b06f52344c.png]: https://img-blog.csdnimg.cn/img_convert/ca2b08367c3d911385e869b06f52344c.png
[61f5706a9f7a1e4722365eeb62143ff5.png]: https://img-blog.csdnimg.cn/img_convert/61f5706a9f7a1e4722365eeb62143ff5.png
[11 _ _-]: https://time.geekbang.org/column/article/71492
[a62ba2e8116a28a4927879830898dd1c.jpeg]: https://img-blog.csdnimg.cn/img_convert/a62ba2e8116a28a4927879830898dd1c.jpeg
[dec46a89917c762bcc48ecc8319ed424.jpeg]: https://img-blog.csdnimg.cn/img_convert/dec46a89917c762bcc48ecc8319ed424.jpeg
[zhangssxyz_xxx.com]: mailto:zhangssxyz@xxx.com
[15 _ _-]: https://time.geekbang.org/column/article/73161
[faaf08c531be9b2651271a098cc8615d.jpeg]: https://img-blog.csdnimg.cn/img_convert/faaf08c531be9b2651271a098cc8615d.jpeg
[67bfd481728623dce711fbe607932b60.jpeg]: https://img-blog.csdnimg.cn/img_convert/67bfd481728623dce711fbe607932b60.jpeg
[3a2ee12e32dc2e13347aa3b3317247d1.png]: https://img-blog.csdnimg.cn/img_convert/3a2ee12e32dc2e13347aa3b3317247d1.png
[0dda37bc56230fa8bac0320fc8c21e60.png]: https://img-blog.csdnimg.cn/img_convert/0dda37bc56230fa8bac0320fc8c21e60.png
[49b427824450bb255c4d0f7db346c8da.png]: https://img-blog.csdnimg.cn/img_convert/49b427824450bb255c4d0f7db346c8da.png
[d1ff9ce61f89cde6af793b2d41453af9.png]: https://img-blog.csdnimg.cn/img_convert/d1ff9ce61f89cde6af793b2d41453af9.png
[75d9649b6e07107c3174193deaf20fcf.png]: https://img-blog.csdnimg.cn/img_convert/75d9649b6e07107c3174193deaf20fcf.png
[a998712d5bbf9a70cca88194b52570b0.png]: https://img-blog.csdnimg.cn/img_convert/a998712d5bbf9a70cca88194b52570b0.png
[16 _ _order by_-]: https://time.geekbang.org/column/article/73479
[60821d231085c73a8375411465755dc4.png]: https://img-blog.csdnimg.cn/img_convert/60821d231085c73a8375411465755dc4.png
[97205ebdb364a8cc46ec3889c649b2e6.png]: https://img-blog.csdnimg.cn/img_convert/97205ebdb364a8cc46ec3889c649b2e6.png
[4eed5ac063a428bef5bd765793021599.jpeg]: https://img-blog.csdnimg.cn/img_convert/4eed5ac063a428bef5bd765793021599.jpeg
[1cfc8579749ec9d5557e954e5a668324.png]: https://img-blog.csdnimg.cn/img_convert/1cfc8579749ec9d5557e954e5a668324.png
[f1f72311c46b2a5510a8eaa4e468b09d.jpeg]: https://img-blog.csdnimg.cn/img_convert/f1f72311c46b2a5510a8eaa4e468b09d.jpeg
[52a1782288e97bccdd5cf06106192fb9.png]: https://img-blog.csdnimg.cn/img_convert/52a1782288e97bccdd5cf06106192fb9.png
[e20177772447428efaad499cab6508d9.png]: https://img-blog.csdnimg.cn/img_convert/e20177772447428efaad499cab6508d9.png
[9a426a52cb62ecfea2c6665e5b41aee6.jpeg]: https://img-blog.csdnimg.cn/img_convert/9a426a52cb62ecfea2c6665e5b41aee6.jpeg
[2d0c96583ee23fb58583f3c6f03cdb60.png]: https://img-blog.csdnimg.cn/img_convert/2d0c96583ee23fb58583f3c6f03cdb60.png
[5360b8ac2c4556bcb4cfd9b72db6993d.jpeg]: https://img-blog.csdnimg.cn/img_convert/5360b8ac2c4556bcb4cfd9b72db6993d.jpeg
[9b5edc236f3a3aef05f86b87ff6d5dec.png]: https://img-blog.csdnimg.cn/img_convert/9b5edc236f3a3aef05f86b87ff6d5dec.png
[18 _ _SQL_-]: https://time.geekbang.org/column/article/74059
[03 _ _-]: https://time.geekbang.org/column/article/68963
[08 _ _-]: https://time.geekbang.org/column/article/70562
[20 _ _-]: https://time.geekbang.org/column/article/75173
[39 _ _-]: https://time.geekbang.org/column/article/80531
[06 _ _ _-]: https://time.geekbang.org/column/article/69862
[07 _ _-]: https://time.geekbang.org/column/article/70215
[19 _ _-]: https://time.geekbang.org/column/article/74687
[21 _ _-]: https://time.geekbang.org/column/article/75659
[30 _ _-]: https://time.geekbang.org/column/article/78427
[40 _ insert_-]: https://time.geekbang.org/column/article/80801
[02 _ _SQL_-]: https://time.geekbang.org/column/article/68633
[12 _ _MySQL_-]: https://time.geekbang.org/column/article/71806
[23 _ MySQL_-]: https://time.geekbang.org/column/article/76161
[24 _ MySQL_-]: https://time.geekbang.org/column/article/76446
[25 _ MySQL_-]: https://time.geekbang.org/column/article/76795
[26 _ _-]: https://time.geekbang.org/column/article/77083
[27 _ _-]: https://time.geekbang.org/column/article/77427
[28 _ _-]: https://time.geekbang.org/column/article/77636
[29 _ _-]: https://time.geekbang.org/column/article/78134
[31 _ _-]: https://time.geekbang.org/column/article/78658
[17 _ _-]: https://time.geekbang.org/column/article/73795
[34 _ _join_-]: https://time.geekbang.org/column/article/79700
[35 _ join_-]: https://time.geekbang.org/column/article/80147
[36 _ _-]: https://time.geekbang.org/column/article/80449
[37 _ _-]: https://time.geekbang.org/column/article/80477
[43 _ _-]: https://time.geekbang.org/column/article/82560
[13 _ _-]: https://time.geekbang.org/column/article/72388
[14 _ count_-]: https://time.geekbang.org/column/article/72775
[22 _ MySQL_-]: https://time.geekbang.org/column/article/75746
[32 _ _kill_-]: https://time.geekbang.org/column/article/79026
[33 _ _-]: https://time.geekbang.org/column/article/79407
[38 _ _InnoDB_Memory_-]: https://time.geekbang.org/column/article/80495
[41 _ _-]: https://time.geekbang.org/column/article/81925
[42 _ grant_flush privileges_-]: https://time.geekbang.org/column/article/82231
[44 _ _-]: https://time.geekbang.org/column/article/82865
[45 _ _id_-]: https://time.geekbang.org/column/article/83183