文章标题：
MySQL日志体系：SQL更新语句执行剖析
文章内容：比如执行这样一条更新语句：
update T set c=c+1 where ID=2;
首先，更新语句的执行会经历查询语句的流程。除此之外，更新操作关联到两个日志模块，分别是redo log和binlog。
redo log
MySQL在进行更新时运用了WAL（预写日志）技术，关键之处在于先记录日志，再将数据写入磁盘。具体而言，当有记录需要更新时，InnoDB引擎会先把记录写入redo log并对内存进行更新，此时更新操作可视为完成。随后，InnoDB会在适当的时候把这个操作记录同步到磁盘中。
InnoDB的redo log是固定大小的，例如可以设置成由4个文件构成，每个文件大小为1GB。它的写入方式是从开头开始写，写到末尾后又会从头开始继续写，如下所示：
这里，write pos代表当前记录的位置，check point代表当前要擦除的位置。当记录被更新到磁盘时，check point会向前移动；当有新的更新操作需要记录时，write pos会向前移动。
所以，有可能出现write pos追上check point的情况。这时候就不能进行新的更新操作，需要先把一部分记录同步到磁盘。
有了redo log，InnoDB能够保证即便数据库发生异常重启，之前提交的记录也不会丢失，这种能力被称作crash-safe。
当设置innodb_flush_log_at_trx_commit=1时，意味着每次事务的redo log都会直接持久化到磁盘。推荐采用这种设置，如此一来可以确保MySQL异常重启后数据不会丢失。
binlog
redo log是InnoDB引擎专有的日志，而binlog是Server层的日志。最初，由于MySQL自带的引擎是MyISAM，不具备crash-safe能力，所以引入InnoDB后，同时使用这两种日志。binlog的主要作用是用于备份。
当设置sync_binlog=1时，表明每次事务的binlog都会持久化到磁盘。推荐采用这种设置，从而保证MySQL异常重启后binlog不会丢失。
两者的具体区别如下：
- redo log是InnoDB引擎特有的，而binlog是Server层实现的。
- redo log属于物理日志，记录“在某个数据页上进行了怎样的修改”；binlog属于逻辑日志，记录这个语句的原始逻辑，比如“给ID=2的行的c字段加1”。
- redo log是循环写入的，空间固定；binlog是追加写入的，写完一个文件后会接着写下一个文件。
介绍完两个日志的概念后，来看执行器与InnoDB引擎完成前面那条更新语句的流程：
- 执行器去找到ID=2的那一行，如果该行所在的数据页在内存中，就直接返回给执行器；不然就需要先从磁盘读入数据页再返回。
- 执行器拿到引擎返回的数据后，进行c+1的操作，得到新的数据。
- 引擎把新数据更新到内存里，同时把这个更新操作记录到redo log中，此时redo log处于prepare状态。然后告知执行器执行完毕，随时可以提交事务。
- 执行器生成该操作的binlog，并把binlog写入磁盘。
- 执行器调用引擎的提交事务接口，引擎把刚写入的redo log改成commit状态，更新完成。
这里redo log的写入分为prepare和commit两个阶段，这就是两阶段提交。
为何需要两阶段提交
以之前的更新语句为例，假设ID=2的行中，字段c初始值为0。假设在执行更新过程中，写完第一个日志但还没写完第二个日志时发生了崩溃。
要是不使用两阶段提交，就会出现两种情况：
- 先写redo log再写binlog。当redo log写完后系统崩溃，依旧能够恢复数据c=1。但binlog中没有记录更新语句，之后用binlog进行备份时，恢复出来的c=0，和原库不一致。
- 先写binlog再写redo log。当binlog写完后崩溃，由于redo log还没写，崩溃后恢复数据c=0。但因为binlog已写完，之后用binlog进行备份时，恢复出来的c=1，和原库不一致。
也就是说，如果不使用两阶段提交，那么恢复临时库或主从备份时就有可能出现不一致的情况。
文章整理自互联网，只做测试使用。发布者：Lomu，转转请注明出处：https://www.it1024doc.com/13067.html
