综述

  1. binlog二进制日志是server层的，主要是左主从复制，时间点恢复使用，在mysql架构属于server层
  2. redo log重做日志是InnoDB存储引擎层的，用来保证事务安全，在mysql架构属于InnoDB层
  3. undo log回滚日志保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读, 在mysql架构属于InnoDB层

6.1 binlog

日志用于记录所有更新且提交了数据或者已经潜在更新提交了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。
1).恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。
2).在主复制服务器上记录所有将发送给从服务器的语句。

一般binlog 用于主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步。用于数据库的基于时间点、位点等的还原操作。binlog 的模式分三种：Statement、Row、Mixed。

6.1.1 Statement

每一条修改数据的 sql 都会记录到 master 的 binlog 中，slave 在复制的时候，sql 进程会解析成和原来在 master 端执行时的相同的 sql 再执行。
优点：在 statement 模式下首先就是解决了 row 模式的缺点，不需要记录每一行数据的变化，从而减少了 binlog 的日志量，节省了 I/O 以及存储资源，提高性能。因为它只需要记录在 master 上执行的语句的细节以及执行语句的上下文信息。
缺点：在 statement 模式下，由于它是记录的执行语句，所以，为了让这些语句在 slave 端也能正确执行，那么它还必须记录每条语句在执行的时候的一些相关信息，即上下文信息，以保证所有语句在 slave 端和在 master 端执行结果相同。另外就是，由于 MySQL 现在发展比较快，很多新功能不断的加入，使 MySQL 的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug 也就越容易出现。在statement 中，目前已经发现不少情况会造成 MySQL 的复制出现问题，主要是在修改数据的时候使用了某些特定的函数或者功能才会出现，比如：sleep() 函数在有些版本中就不能被正确复制，在存储过程中使用了 last_insert_id() 函数，可能会使 slave 和 master 上得到不一致的 id 等等。由于 row 模式是基于每一行来记录变化的，所以不会出现类似的问题。

6.1.2 Row

日志中会记录每一行数据被修改的形式，然后在 slave 端再对相同的数据进行修改。row 模式只记录要修改的数据，只有 value，不会有 sql 多表关联的情况。
优点：在 row 模式下，binlog 中可以不记录执行的 sql 语句的上下文相关的信息，仅仅只需要记录哪一条记录被修改了，修改成什么样了，所以 row 的日志内容会非常清楚的记录下每一行数据的修改细节，非常容易理解。而且不会出现某些特定情况下的存储过程和 function，以及 trigger 的调用和触发无法被正确复制问题。
缺点：在 row 模式下，当所有执行语句记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。

6.1.3 Mixed

从官方文档中看到，之前的 MySQL 一直都只有基于 statement 的复制模式，直到 5.1.5 版本的 MySQL 才开始支持 row 复制。从 5.0 开始，MySQL 的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给 MySQL Replication 又带来了更大的新挑战。另外，看到官方文档说，从 5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 也对 row 模式做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。

6.2 undo log

  • 生命周期

事务开始之前，将当前事务版本生成 undo log，undo log 也会产生 redo log 来保证 undo log 的可靠性。当事务提交之后，undo log 并不能立马被删除，而是放入待清理的链表，由 purge 线程判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息，从而决定是否可以清理 undo log 的日志空间。

  • 存储内容

undo log 存储的是逻辑格式的日志，保存了事务发生之前的上一个版本的数据，可以用于回滚。当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着 undo 链找到满足其可见性的记录。

  • 存储位置

默认情况下，undo 文件是保存在共享表空间的，也即 ibdatafile 文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的 undo log 信息，这些信息全部保存在共享表空间中，因此共享表空间可能会变得很大，默认情况下，也就是 undo log 使用共享表空间的时候，被“撑大”的共享表空间是不会、也不能自动收缩的。因此，MySQL5.7 之后的“独立 undo 表空间”的配置就显得很有必要了。

6.3 redo log

事务开始之后，就开始产生 redo log 日志了，在事务执行的过程中，redo log 开始逐步落盘，当对应事务的脏页写入到磁盘之后，redo log 的使命就完成了，它所占用的空间也就可以被覆盖了。

  • 存储内容

redo log 包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的，redo log 存储的是物理格式的日志，记录的是物理数据页面的修改信息，它是顺序写入 redo log file 中的。

  • 落盘方式（将 innodb 日志缓冲区的日志刷新到磁盘）

1，Master Thread 每秒一次执行刷新 Innodb_log_buffer 到重做日志文件
2，每个事务提交时会将重做日志刷新到重做日志文件
3，当重做日志缓存可用空间少于一半时，重做日志缓存被刷新到重做日志文件

总结：
就是在事务开始的时候，数据库会在日志文件中记录要执行的数据，等事务完成后，再把数据同步到数据库中。这个记录文件是固定大小，并且会被覆盖的。

6.4 总结

binlog 就相当于在git所有的提交记录的明细一样，通过解析所有的提交明细，就能获取到所有的代码。
redo log 就相当于提交代码的时候 先提交到本地，检查一下后确保没问题，在提交到仓库。
undo log 就是每一次的提交记录，会记录提交前是什么，提交后是什么，可以回滚代码。

mvcc

在第二节的时候我们看到mysql会发生 脏读 幻读 不可重复读，可以采用读未提交 读已提交 可重复读 串行化 等四种隔离级别来解决这些问题，mysql默认的是可重复读级别。
那如何实现读未提交 ，读已提交，可重复读些场景呢，mysql通过undolog来实现mvcc机制来解决这些问题。

MVCC多版本并发控制机制
Mysql在可重复读隔离级别下如何保证事务较高的隔离性，我们上节课给大家演示过，同样的sql查询语句在一个事务里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。
这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的，对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的。
Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。

undo日志版本链与read view机制详解
undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链(见下图，需参考视频里的例子理解)
clipboard.png

image.png

在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束之前都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成)，这个视图由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成，事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。
版本链比对规则：

  1. 如果 row 的 trx_id 落在绿色部分( trx_id<min_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；
  2. 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的）；
  3. 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况
    a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自己的事务是可见的)；
    b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。

对于删除的情况可以认为是update的特殊情况，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数据。

注意：begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作InnoDB表的语句，事务才真正启动，才会向mysql申请事务id，mysql内部是严格按照事务的启动顺序来分配事务id的。

总结：
MVCC机制的实现就是通过read-view机制与undo版本链比对机制，使得不同的事务会根据数据版本链对比规则 读取同一条数据在版本链上的不同版本数据。
其实就是当执行查询的时候会生成整个库的readview,不管再这个查询的事务中再执行多少查询，还是根据之前生成的readview 去undolog中去按照一定的算法去寻找数据，那当然可以解决脏读和不可重复读的问题了。为什么解决不了幻读，因为这个时候如果其他事务新增了一条数据，那么之前生成的readview 肯定没有新数据的相关信息，那么幻读肯定还是解决不了的。

至于算法可能按照上面 有点麻烦，其实这个算法的核心还是要找到我发生查询请求 也就是readview生成的时候找 已经提交事务的最大id,那条数据就是要查询的数据，只不过算法实现看着麻烦罢了。

Innodb引擎SQL执行的BufferPool缓存机制
image.png
为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？
因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能可能相当差。
因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。
Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。
更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。
正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。