一条update如何执行_redo_undo_二阶段

1. 准备工作

1.1 知识前提

了解： 一条SQL查询语句是如何执行的

1.2 数据准备

mysql> show create table t1;
| Table | Create Table                                                                                                                                             |
+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------+
| t1    | CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
1 row in set (0.00 sec)

插入三条数据

mysql> insert into t1 values (null,'zhangsan');
Query OK, 1 row affected (0.01 sec)

mysql> insert into t1 values (null,'lisi');
Query OK, 1 row affected (0.00 sec)

mysql> insert into t1 values (null,'wanger');
Query OK, 1 row affected (0.01 sec)

更新数据

mysql> update t1 set name='zhangsan1' where id =1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

涉及到修改数据，SQL执行流程和涉及到的日志。

2 操作顺序

• 查找记录
  查找记录：执行器先找引擎取id=1这一行。ID是主键，引擎直接用树搜索找到这一行。如果id=1这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回；
• 得到新数据
  执行器拿到引擎返回的行数据，把name改为zhangsan2，得到新的一行数据，再调用引擎接口写入这行新数据；
• 跟新到内存,prepare
  引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态；
• 告知执行器
  引擎告知执行器，执行完成了，可以调接口提交事务；
• 写入binlog
  执行器生成这个操作的binlog，并把binlog写入磁盘。
• 事务提交,commit
  执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交commit状态，更新完成。

3 日志

3.1 重做日志 redo log

redo log 通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页

一般更新会有如下做法：
直接查询原始数据，立马更新； 先找个临时记事本，做下记录，等不忙的时候/结算时候进行核算更新。

第一种做法在高并发IO的情况下非常的不容乐观。所以一般都会采用第二种方式。

同样在MySQL里存在这样的一个问题，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。为了解决这个问题，MySQL的设计者就用了redo log的思路来提升更新效率。

临时记事本和原始数据进行操作的整个过程，也是对应MySQL里经常说到的WAL(预写式日志)技术，WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。具体来说，当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log（记事本）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个记事本里的记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。

3.2 归档日志 binlog

MySQL整体来看，其实就有两块：一块是Server层，它主要做的是MySQL功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。上面redo log是InnoDB引擎特有的日志，而Server层也有自己的日志，称为binlog（归档日志）。

这两种日志有以下三点不同。
redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑.

redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

4 二阶段提交

4.1 XID

binlog是MySQL内部实现二阶段提交的协调者，它为每个事务分配一个事务ID: XID

• 一阶段：
  开启事务，redo log 和 undo log已经记录了对应的日志，此时事务状态为prepare

• 二阶段：
  发送commit，清除undo信息，刷redo，设置事务状态为completed

4.1 如何判断binlog和redolog是否达成了一致

当MySQL写完redolog并将它标记为prepare状态时，并且会在redolog中记录一个XID，它全局唯一的标识着这个事务。而当设置sync_binlog=1时，做完了上面第一阶段写redolog后，mysql就会对应binlog并且会直接将其刷新到磁盘中。

binlog结束的位置上也有一个XID。

只要这个XID和redolog中记录的XID是一致的，MySQL就会认为binlog和redolog逻辑上一致。就上面的场景来说就会commit，而如果仅仅是rodolog中记录了XID，binlog中没有，MySQL就会RollBack

mysql> show binlog events in 'mysql-bin.000007';
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+
| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                                                  |
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+
| mysql-bin.000007 |   4 | Format_desc    |      1116 |         123 | Server ver: 5.7.41-log, Binlog ver: 4                                 |
| mysql-bin.000007 | 123 | Previous_gtids |      1116 |         194 | 222a1bac-bc89-11ed-8046-000c2945c1f2:1-88504                          |
| mysql-bin.000007 | 194 | Gtid           |      1116 |         259 | SET @@SESSION.GTID_NEXT= '222a1bac-bc89-11ed-8046-000c2945c1f2:88505' |
| mysql-bin.000007 | 259 | Query          |      1116 |         332 | BEGIN                                                                 |
| mysql-bin.000007 | 332 | Table_map      |      1116 |         394 | table_id: 110 (dbsql.emp)                                             |
| mysql-bin.000007 | 394 | Delete_rows    |      1116 |         725 | table_id: 110 flags: STMT_END_F                                       |
| mysql-bin.000007 | 725 | Xid            |      1116 |         756 | COMMIT /* xid=16 */                                                   |
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+
7 rows in set (0.01 sec)

4.1 如果不用两阶段提交

由于redo log和binlog是两个独立的逻辑，如果不用两阶段提交，要么就是先写完redo log再写binlog，或者采用反过来的顺序。

我们看看这两种方式会有什么问题。
update语句来做例子，当前ID=1的行，字段name的值是zhangsan。

• 先写redo log，后写binlog
  假设在redo log写完了，但binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行name的值是zhangsan1。但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行name的值就是zhangsan，与原库的值不同。

• 先写binlog，后写redo log
  如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行name的值是zhangsan。但是binlog里面已经记录了“把name从zhangsan改成zhangsan1”这个日志。所以，在之后用binlog来恢复的时候，恢复出来的临时库中的这一行c值就是zhangsan1，与原库的值不同。
  可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
  简单说，redo log和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。