SQL语句执行原理

目录

1.查询语句是如何执行的

1.1 MySQL的逻辑架构图

1.1.1 连接器

1.1.2 查询缓存

1.1.3 分析器

1.1.4 优化器

1.1.5 执行器

1.2 问题

2.更新语句是如何执行的

2.1 redo log

2.2 binlog

2.3 两阶段提交

---

1.查询语句是如何执行的

假设我们有个最简单的表，表里只有一个ID字段，再执行下面一条查询语句：

mysql> select * from T where ID=10；

我们看到的只是输入一条语句，返回一个结果，却不知道这条语句在MySQL内部的执行过程。为了解释这个问题，我们首先看一下MySQL的基本架构示意图，从中我们可以清楚的看到SQL语句在MySQL的各个功能模块中的执行过程。

1.1 MySQL的逻辑架构图

MySQL的逻辑架构图如下图所示：

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

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

存储引擎层主要负责数据的存储和提取。

1.1.1 连接器

连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般为：

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

输入命令之后，就需要在交互对话里面输入密码。如果用户名和密码认证通过，连接器就会到权限表里面查出账号拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。这就意味着，一个用户成功建立连接后，即使用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。

连接成功以后，如果没有后续动作，这个连接就会处于空闲状态，我们可以在show processlist命令中看到它。执行结果如下：

mysql> show processlist;
+---------+------+---------------------+---------+---------+------+----------+------------------+
| Id      | User | Host                | db      | Command | Time | State    | Info             |
+---------+------+---------------------+---------+---------+------+----------+------------------+
| 1050383 | root | 101.86.136.19:17307 | mysql   | Sleep   |  611 |          | NULL             |
| 1050384 | root | 101.86.136.19:17332 | my-test | Sleep   |  726 |          | NULL             |
| 1050385 | root | 101.86.136.19:17333 | my-test | Sleep   |  726 |          | NULL             |
| 1050386 | root | 101.86.136.19:17765 | NULL    | Query   |    0 | starting | show processlist |
+---------+------+---------------------+---------+---------+------+----------+------------------+
4 rows in set (0.04 sec)

其中的Command列显示为“Sleep”，表示现在系统中有一个空闲连接。客户端如果超过一段时间没有操作，连接器就会自动将它断开。这个时间是由参数wait_timeout控制的，默认值是8小时。

数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。连接的建立过程，通常是比较复杂的，所以一般我们尽量使用长连接。

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

如果解决这个问题呢？我们可以考虑如下方案：

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

1.1.2 查询缓存

MySQL拿到查询请求后，会先到查询缓存中去查找有没有执行过该SQL语句。如果已经执行过，就会将缓存结果直接返回给客户端。如果不在查询缓存中，就会执行后面的操作；执行完成后，执行结果会被存入查询缓存中。

但是大多数情况下，通常不建议开启查询缓存，因为查询缓存往往弊大于利。查询缓存的失效是非常频繁的，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。对于更新比较频繁地数据库来说，查询缓存的命中率是非常低效的。除非你的业务是一张静态表，很长时间才会更新一次。

MySQL8.0版本已经将查询缓存的整块功能删除了，也就是说8.0版本已经彻底没有这个功能了。

1.1.3 分析器

分析器会先做“词法分析”，SQL是由多个字符串和空格组成的，MySQL需要识别出里面的字符串分别是什么，代表什么。比如，MySQL从输入的“select”关键字识别出来这个一个查询语句；把字符串“T”识别成“表名T”，把字符串“ID”识别成“列ID”。

根据词法分析的结果，语法分析器会根据语法规则，判断输入的这个SQL是否满足MySQL语法。如果语法不对，就会收到“You have an error in your SQL syntax”的错误提示。

1.1.4 优化器

优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联的时候，决定各个表的连接顺序。比如执行下面的两个表的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通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是进入了执行器阶段，开始执行语句。开始执行的时候，要先判断对该表有没有查询权限，如果没有就返回没有权限的错误。如果有，则打开表继续执行。

1.2 问题

如果表T中没有字段k，而执行了语句select * from T where k=1，那肯定会报“不存在这个列”的错误，那这个错误在哪个阶段报出来的呢？

答：分析器。MySQL会在分析阶段判断语句是否正确，表是否存在，列是否存在等。

2.更新语句是如何执行的

我们首先从一张表的更新语句说起，下面是这个表的建表语句：

create table T(ID int primary key,c int)

如果将ID=2这一行的值加1，SQL语句会这样写：

update T set c=c+1 where ID=2

首先可以确定的是查询语句的那一套流程，在更新语句同样适用：

1. 在一个表中有更新的时候，跟这个表有关的查询缓存都会失效，所以这条语句首先会把表T上的所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因。
2. 接下来，分析器会通过词法和语法解析这条更新语句；优化器决定要使用ID这个索引；最后，执行器负责具体执行，找到这一行，进行更新。

与查询流程不一样的是，更新流程还涉及两个重要的日志模块，redo log（重做日志）和binlog（归档日志）。

2.1 redo log

在MySQL中如果每次更新操作都需要写进磁盘，然后磁盘要找到对应的记录，然后再更新，整个过程IO成本、查找成本都很高。为了解决这个问题，MySQL的设计者引入了redo log。具体来说，当有一条记录需要更新的时候，InnoDB引擎会先把记录写到redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。

InnoDB的redo log是固定大小的，比如可以配置为1组4个文件，每个文件的大小是1GB，那么总共就可以记录4GB的操作。从头开始记录，写到末尾就又回到开头循环写，如下图所示：

write pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

writepos和checkpoint之间的是空闲部分，可以用来记录新的操作。如果writepos追上了checkpoint，表示redo log已经满了，这时候不能再进行新的更新，得先擦除一些记录，把checkpoint推进一下。

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录也不会丢失，这个能力称为crash-safe。

2.2 binlog

前面我们说过，MySQL整体来看，就是就有两块：一块是Server层，主要做MySQL功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。redo log是InnoDB引擎特有的日志，而Server层也有自己的日志，称为binlog。

这两种日志主要有以下三点区别：

• redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。
• redo log是物理日志，记录的是“某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1”
• redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

有了对这两个日志概念的理解，我们再来看执行器和InnoDB引擎在执行这个简单的update语句时的内部流程：

1. 执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2. 执行器拿到引擎给的行数据，把这个值加上1，比如原来的值是N，现在就是N+1，得到新的一行数据，再调用引擎接口写入这行数据。
3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log中，此时redo log处于prepare状态，然后告诉执行器执行完成了，随时可以提交事务。
4. 执行器生成这个操作的binlog，并把binlog写入磁盘。
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交（commit）状态，更新完成。

执行流程示意图，如下图所示：

MySQL将redo log的写入拆分成了两个步骤：prepare和commit，这就是“两阶段提交”。

2.3 两阶段提交

为什么必须有“两阶段提交”呢？是为了让两份日志之间的逻辑一致。要解释这个问题，我们先解释一下如何让数据库恢复到半个月任意一秒的状态。

如果DBA承诺说半个月内可以恢复任意一秒的状态，那么备份系统中一定会保存最近半个月的所有binlog，同时系统会定期做整库备份。定期时间可以是一天一备，也可以是一周一备。当需要恢复到指定的某一秒时，我们可以这么做：

• 首先，找到最近的一次全量备份，从这个备份恢复到临时库。
• 然后，从备份的时间点开始，将备份的binlog依次取出来，重放到误删表之前的那个时刻。
• 最后将表数据从临时库中取出来，按需恢复到线上库中。

这样临时表就跟误删之前的线上库一样了，然后就可以把表数据从临时库中取出来，恢复到线上库中了。

聊完数据恢复过程，我们来谈谈为什么需要“两阶段提交”。由于redo log和binlog是两个独立的逻辑，如果不用两阶段提交，要么就是先写完redo log再写binlog，或者采用相反的顺序。我们来看看这两种方式有什么问题：

• 先写redo log后写binlog。假设redo log写完，binlog还没写完的时候，MySQL进程异常重启。redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，但是由于binlog没有写完，这时候binlog里面就没有这条记录。如果需要用这个binlog来恢复临时库的话，这个临时库就会缺少这一次更新。
• 先写binlog后写redo log。如果在binlog写完之后crash，由于redo log还没写，崩溃恢复之后这个事务无效。但是binlog里面已经记录了，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的数据就会与原库的值不同。

可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。其实，不只是误操作后需要用这个过程来恢复数据，当需要扩容的时候，也就是需要再多搭建一些备库来增加系统的读能力的时候，目前最常见的解决方案是用全量备份加上应用的binlog来实现的，这个“不一致”就会导致线上出现主从数据库不一致的情况。

最后，总结一下两阶段提交的过程：

prepare->写binlog->commit

当在写binlog-之前崩溃时，恢复后发现没有commit，因此回滚。当在commit之前崩溃时，恢复后虽然没有commit，但满足prepare和binlog完整，所以会自动commit。