Mysql日志详解

Mysql主要有三大日志，分别为redo log，undo log，binlog；从这三个日志可以分析Mysql的事务原理

1.事务原理

事务 是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。

特性

1. 原子性 事务是不可分割的最小操作单元，要么全部成功，要么全部失败
2. 一致性 事务完成时，必须使所有的数据都保持一致状态。
3. 隔离性 数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环
   境下运行
4. 持久性 事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。

我们研究事务的原理，就是研究MySQL的InnoDB引擎是如何保证事务的这四大特性的
其中的原子性、一致性、持久化，实际上是由InnoDB中的两份日志来保证的，一份是redo log日志，一份是undo log日志。 而持久性是通过数据库的锁，加上MVCC来保证的。

2.redo log

重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。
该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo logfile）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中, 用于在刷新脏页到磁盘,发生错误时, 进行数据恢复使用。

每条 redo 记录由“表空间号+数据页号+偏移量+修改数据长度+具体修改的数据”组成

简而言之

1. 事务提交时，从bufferpool 刷新到磁盘可能会发生错误，于是在事务增删改时，先将操作的数据页变化，记录在redo log buffer 中
2. 事务提交将redo log buffer数据刷新到redo log磁盘文件中
3. 如若刷新缓冲区脏页到磁盘发生错误，借助redo log进行数据恢复，保证事务持久性
4. 如若buffer pool脏页成功刷盘，此时的redo log失效，可以删除，磁盘中存在多个redo log循环写入。

疑问：redo log buffer数据刷新到redo log磁盘文件这个过程出错的概率

redo log buffer刷盘时机
innodb_flush_log_at_trx_commit 参数

• 0 ：设置为 0 的时候，表示每次事务提交时不进行刷盘操作
• 1 ：设置为 1 的时候，表示每次事务提交时都将进行刷盘操作（默认值）
• 2 ：设置为 2 的时候，表示每次事务提交时都只把 redo log buffer 内容写入 page cache

3.undo log

回滚日志，用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和MVCC(多版本并发控制) 。

undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo
log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的
update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

Undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些
日志可能还用于MVCC。

4. MVCC

当前读：读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加
锁。
快照读：简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，
不加锁，是非阻塞读

全称 Multi-Version Concurrency Control，多版本并发控制。 指维护一个数据的多个版本，
使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需
要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

隐藏字段

• DB_TRX_ID：最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID。
• DB_ROLL_PTR：回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本
  本。
• DB_ROW_ID：隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。

版本链

实例
有一张原始表数据为：

然后，有四个并发事务同时在访问这张表

形成的版本链表如下

红色为undo log中内容。
修改记录过程如下

1. 当事务2执行第一条修改语句时，会记录undo log日志，记录数据变更之前的样子; 然后更新记录，
   并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
2. 当事务3执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记
   录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
3. 当事务4执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记
   录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。

最终我们发现，不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条
记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。

readview
ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务
（未提交的）id。

不同的隔离级别，生成ReadView的时机不同：

• READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。
  分析事务5两次快照读，设置隔离级别为读已提交，所以每一次进行快照读
  都会生成一个ReadView
  第一次查询形成的readview
  m_id={3,4,5}; min_trx_id=3,max_trx_id=6,creator_trx_id=5;
  匹配到事务2提交的数据

第二次查询形成的readview
m_id={4,5}; min_trx_id=4,max_trx_id=6,creator_trx_id=5;
匹配到事务3提交的数据

• REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。
  仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。
  第一次查询形成的readview
  m_id={3,4,5}; min_trx_id=3,max_trx_id=6,creator_trx_id=5;
  匹配到事务2提交的数据
  后续都是复用该ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返回的结果也是一样的

如何实现可重复读？
其实就是RR级别下复用了readview，导致读取的数据的版本都是一致的。

所以呢，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。
而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。

5.binlog

binlog 是逻辑日志，记录内容是语句的原始逻辑，不管用什么存储引擎，只要发生了表数据更新，都会产生 binlog 日志。
可以说MySQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。

事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。

redo log（重做日志）让InnoDB存储引擎拥有了崩溃恢复能力。
binlog（归档日志）保证了MySQL集群架构的数据一致性。

两阶段提交保证redolog与binlog一致性
在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的写入时机不一样。
由于binlog没写完就异常，这时候binlog里面没有对应的修改记录。因此，之后用binlog日志恢复数据时，就会少这一次更新
使用两阶段提交后，写入binlog时发生异常也不会有影响，因为MySQL根据redo log日志恢复数据时，发现redo log还处于prepare阶段，并且没有对应binlog日志，就会回滚该事务。