在上一篇文章中,我们从一个查询语句的执行流程知道了 MySQL 架构可分为 Server 层和存储引擎层,以及各个层级的具体部件。
那么在这篇文章中,小鱼将介绍更新语句的执行流程,从中我们又能学到什么呢?
我们先创建一张表作为演示表,作为演示表只需要一个主键、一个额外字段就可以了。下面是演示表的创建语句:
CREATE TABLE test(ID int primary key, age int);
如果我们需要将 ID=2
目标值自增 1,更新的 SQL 语句如下。
UPDATE test SET age=age+1 WHERE ID=2;
更新目标值时,得先查找的该行数据,所以也会执行SQL查询语句的流程。
上面提到的两次写入日志redo log和binlog,就是MySQL的两阶段提交,是为了保证数据的一致性。这里后文会写一篇文章进行单独介绍。
更新语句流程与查询语句流程不一样的地方在于日志模块,更新语句涉及到两个十分重要的日志模块——redo log(重做日志)和 binlog(归档日志)。
Redo Log
称为重做日志,提供再写入操作,恢复提交事务修改的页操作,用来保证事务的持久性。
mysql 数据是被持久化写进磁盘的,每次更新也需要找到目标数据,在进行修改,每次更新都执行一遍该操作,这个过程的 IO 成本是比较高的。
为了解决这个问题,MySQL 采用了先写日志,空余时间再写磁盘的思路来提升更新效率。即是 WAL 技术(预写式日志,WAL 的全称是 Write-Ahead Logging)。
具体来说,当有更新语句执行的时候,InnoDB 引擎会先把更新记录写到 redo log 日志里,并更新内存,这个时候已经完成更新(内存上),实际磁盘上的数据尚未更新。等适当的时候(通常是系统空闲的时候),InnoDB 引擎会将这个操作记录(redo log 中记录的更新语句)更新到磁盘。
写 redo log
的流程如下:
Redo Log Buffer
,记录的是数据被修改后的值。Redo Log Buffer
中的内容采用追加写的方式刷新到 Redo Log File
。这样做还有一个问题,InnoDB 的 redo log 日志的大小是固定的,它设计的是循环的,即日志文件写满后会覆盖掉最先的记录(从头开始写,写到末尾就又回到开头循环写)。
write pos
:当前记录的位置,一边写一边后移,当写到第 3 号文件末(末尾)时会回到 0 号文件(开头)开头。checkpoint
:当前要擦除的位置,同样是往后推移并且循环的,擦除记录前要把记录更新到数据文件(更新到磁盘里)。write pos
和 checkpoint
之间:redo log
日志文件还空着的部分,可以用来记录新的操作。 write pos
追上 checkpoint
,表示 redo log
日志文件写满了,此时不能再执行新的更新操作,会将记录写入数据文件,并执行擦除记录,推进 checkpoint
位置。试想:对于已经写入 redo log
的记录,在数据库异常重启后,能否恢复?
mysql 重启后,已经写入 redo log
的记录不会丢失,这个能力也称为 crash-safe
。
crash-safe
还有个重要的日志——Binlog 日志。
MySQL 架构分为 Server 层和存储引擎层,redo log
是存储引擎层产生的日志,而 server 层也有日志——Binlog 归档日志。
两者的区别在于以下几点:
Redo log
是 InnoDB 引擎特有的;binlog
是 MySQL 的 Server 层产生的,任何引擎都存在该日志。Redo log
是循环写的,空间固定会用完,用完即从头开始写。binlog
是追加写,即 binlog
文件写到一定大小后会新建日志文件,不会覆盖掉以前的日志。redo log
会不断记录,而 binlog
只有在事务提交的时候才记录。Redo log
是物理日志,详细记录了“在某个数据页上做了什么修改”(包含事务的过程操作);binlog 是逻辑日志,记录的是语句的原始逻辑(对数据最终的影响)。譬如:一个事务对表做10万行的记录插入,在事务执行过程中,会一直不断的往 Redo Log
顺序写,而这个过程 Binlog
不会记录,直至这个事务提交的时候,才会写入到 Binlog
文件中。
这两份日志存在的意义就是实现 crash-safe 能力。
这两个日志文件结合起来,才真正实现了 crash-safe 能力,让 MySQL 既能保证事务的 ACID 属性,又能支持高效的数据复制和恢复能力。
查看 redo log 和 binlog 设置
show variables like 'innodb_flush_log_at_trx_commit';
show variables like 'sync_binlog'
innodb_flush_log_at_trx_commit
: sync_binlog
这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘。对于需要高度数据持久性和不能承受数据丢失的系统,建议将 sync_binlog
设置为 1
。设置 redo log 和 binlog 配置
可以在 MySQL 配置文件(通常是 my. Cnf 或 my. Ini)中设置这个变量。设置好后需要重启 mysl,使得配置生效。
[mysqld]
sync_binlog=1
innodb_flush_log_at_trx_commit = 1
或者,也可以在 MySQL 运行时动态设置,但是这种变更只对新的会话有效,对于已经存在的会话,该设置直到会话结束才会生效。
SET GLOBAL sync_binlog=1;
SET GLOBAL innodb_flush_log_at_trx_commit = 1;