首页 > 数据库 > MySQL

MySQL日志系统之一条SQL更新语句是如何执行的？

来源：SegmentFault

时间：2023-02-24 20:02:03 189浏览收藏

你在学习数据库相关的知识吗？本文《MySQL日志系统之一条SQL更新语句是如何执行的？》，主要介绍的内容就涉及到MySQL，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

前言

当我们执行一条

sql

更新语句时，你有没有想过，它的在

MySQL

系统内部是如何去执行的？当我们购买

MySQL

服务器时，你有没有考虑过为什么

MySQL

服务器内存大，硬盘为

SSD

的话比较好？（当然，这是废话，什么服务器，内存大，硬盘为

SSD

都好，但

MySQL

服务器要求还是比业务代码服务器要求高些）
以下我们以表

的

update sql

为例进行分析（默认

InnoDB

引擎）：

create table T(ID int primary key, c int);
update T set c=c+1 where ID=2;

执行逻辑

一个

update

语句的执行逻辑为：
1、通过连接器连接

MySQL Server层

；
2、连接器阶段初步分析为

update

交给分析器处理；
3、分析器详细分析

update

语句，进行词法、语法、语义检查，生成解析树以供优化器使用，并在交给优化器之前进行权限检查

（precheck）

；
4、优化器将解析树优化，生成最优执行计划，交给执行器执行；
5、执行器在执行

sql

时会再次检查权限，并调用引擎层提供的数据接口，对数据进行更新处理。

更新语句和查询语句不同之处在于，当我们执行更新时，对数据的敏感性是比较强的，我们需要保证数据更新正确，且万一的万一，

MySQL

崩溃了，我们也能恢复数据，所以更新操作涉及到记录日志，这里的日志就是我们熟知的

MySQL Server层

的

binlog日志

和

InnoDB

引擎层的

redolog日志

。

所以，

update

时，在上面执行逻辑中的第5步执行器执行阶段的处理过程为：
1、执行器取

ID=2

的数据；
2、引擎判断数据页是否在内存中，没有则从磁盘读取到内存中，从内存中返回行数据；（内存大的服务器的好处）
3、执行器将该数据值加1，之后写入新行，通知引擎
4、引擎将新数据更新到内存中
5、引擎此时开始记录

redolog

，并将该记录置为prepare状态
6、执行器写

binlog

7、引擎提交事务，并更新此行数据的

redolog

状态为

commit

8、当

MySQL

空闲时，会将内存中的数据落盘。
流程图：【深色为执行器执行，浅色为引擎处理】

以上就是更新数据时，执行器和引擎做的一系列操作。

整个更新过程其实是

AWL

技术，即

Write-Ahead Logging

预写式日志。先写日志，再更新。

分析

我们可能会有疑问：为什么在

binlog

存在的情况下，我们还要额外引入

redolog

呢？

我们详解之前，先讨论下

binlog

和

redolog

是什么。

binlog

是

MySQL Server层

提供的日志记录功能，所有引擎都能用，它是记录

sql

执行逻辑的，如给ID=2这一行的c字段+1，且

binlog

日志是追加记录的，当文件写到一定大小会新增一个新文件继续记录，属于全量日志。

redolog

则是

InnoDB

独有的日志，其他引擎不可用，且

redolog

记录的是在某个数据页上做了什么修改，属于物理日志，只有

InnoDB

才能用，且是固定大小，循环记录的。

现在我们来分析为什么

binlog

和

redolog

并存的问题。

binlog

和

redolog

是通过事件ID去关联的。
简单来说，

binlog

和

redolog

并存可以保证数据一致性，以及意外宕机时的数据恢复问题。也就是

MySQL

的

crash-safe

。

如果我们只记录
```
binlog
```
，那么我们只有操作记录，如果日志记录了，但是数据没更新到表里，当我们使用
```
binlog
```
恢复表时，会出现数据不一致。
单独记录
```
redolog
```
是不行的，因为
```
redolog
```
是循环记录的，会抹去旧的日志，不像
```
binlog
```
一样，是全量的。（资料显示，现在已经有在做
```
redolog
```
全量存储的第三方团队了，基于数据页的数据恢复一致性更强，且不用记两份日志）
如果先记录
```
binlog
```
再记录
```
redolog
```
的话，若写完
```
binlog
```
数据库崩了，此时没有记录
```
redolog
```
，当重启数据库时，因为
```
redolog
```
没记录，所以此事务操作无效，库中值不会改变，但是
```
binlog
```
中又有此条记录，导致使用
```
binlog
```
恢复数据时，会更新值，导致数据不一致。
如果先记录
```
redolog
```
再记录
```
binlog
```
的话，若写完
```
redolog
```
数据库崩了，此时没有记录
```
binlog
```
，重启数据库，虽然能通过
```
redolog
```
正确恢复到之前的数据更新，但是因为
```
binlog
```
没记录，之后备份恢复时，还是会导致数据不一致。