Mysql三大日志

Undo Log

作用：

1、当事务发生异常需要撤回时，可以利用undo log使得数据回滚到事务之前（事务的原子性）

2、Mvcc

事务回滚原理：

这个好理解，每一个事务开始前，都会将旧的数据记录到undo log日志中，一旦事务回滚，就会将数据更改为undo log记录的数据

• 在插入一条记录时，要把这条记录的主键值记下来，这样回滚时只需要把这个主键值对应的记录删掉就好了；
• 在删除一条记录时，要把这条记录中的字段的内容都记下来，回滚时只要把这些内容再写进硬盘就好了
• 在更新一条记录时，要把被更新的列的旧值记下来，这样之后回滚时再把这些列更新为旧值就好了。（更新时的旧数据是存在Buffer Pool的Undo页里的）

Mvcc原理：

在undo log中，一条记录的字段除了我们自己定义的以外，还包括trx_id和roll_pointer，其中trx_id相当于事务的版本是递增的，roll_pointer是一个指针，指向该版本的上一条版本，从而形成一条版本链，当一条记录被更新时，就会生成一条undo log的记录，且该记录的trx_id为最新版本的trx_id+1

版本链：

在读已提交的级别下，每进行一次读操作，都会生成一个ReadView，这个ReadView里也会包含一个trx_id，读的过程中会去版本链中去找第一个比ReadView里的trx_id小的记录。

在可重复读的级别下，只会在事务的开启阶段生成一个ReadView，这个ReadView里同样会包含一个trx_id，读的过程中会去版本链中去找第一个比ReadView里的trx_id小的记录。

举个例子：

假设此时有两个同时进行的事务（此时最新版本为10，也就是黄色部分还未提交），一个事务执行update操作，另一个执行select操作，在可重复读的级别下，假设update还未提交，此时select会创建一个ReadView，这个ReadView里最小的trx_id应该是11，就会读取年龄为20的张三，当update提交后，最新的记录的版本为11，这时候，再去读取，由于ReadView最小的trx_id并不大于11，就会向下去找，找到10，然后读取

Redo Log

作用：

1、保证事务的持久性

如何保证持久性？

Mysql想保证持久性，有一个简单的办法——没执行一次增、删、改就将新的数据写到磁盘中。但是，由于与磁盘交互的速度太慢，Mysql为了提高速度，开了一个缓存——Buffer Pool，每当来一个增、删、改，先将内容写道Buffer Pool缓存中，然后由其他线程定期的将缓存刷到磁盘中。但是，由于内存的可靠性低，一旦服务宕机，数据就丢失了。为了解决这个问题，就要靠Redo Log了。

Redo Log如何让保证持久性？

有了Redo Log，每来一个增、删、改，都会将它写到Redo Log里，这样，假如服务宕机了，可以根据Rdoo Log来恢复数据。

写到Redo Log里也是写到磁盘，为何要多次一举？  

虽然写到Redo Log和写到idb文件都是写到盘里，但是写到idb文件时需要先查询到原数据的位置再插入（随机写），而写到Redo Log是以追加的方式，不需要查询（顺序写），这样就会快很多。

虽然顺序写比随机写速度快，但毕竟是与磁盘交互，速度还是很慢 。针对这一问题，Mysql 由设置了一个缓存 —— redo log buffer，并设置了一个参数 innodb_flush_log_at_trx_commit 来控制缓存到磁盘的策略， 这个参数有三个取值 0、1、2 默认为1

• 当该参数为 0 ，每次事务提交时 ，还是将 redo log 留在 redo log buffer 中 ，该模式下在事务提交时不会主动触发写入磁盘的操作。
• 当该参数为 1 ，每次事务提交时，都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘，这样可以保证 MySQL 异常重启之后数据不会丢失。
• 当该参数为 2 ，每次事务提交时，都将缓存在 redo log buffer 里的 redo log 写道redo log的 文件缓存（操作系统层面） 中，这样可以保证 MySQL 异常重启之后数据不会丢失。

 Redo Log满了会发生什么？