mysql5.7事务的原理和MVCC，redo log与bin log的区别

WAL机制 write ahead logging  预写日志，写完日志，再写入实际数据文件。

redo log  保证事务的持久性
undo log 保证事务的一致性

redo日志记录内容：表空间id，页id，页面上的偏移量，偏移量改了什么值，这样记录空间就很小。而且记录是一条一条产生的，是一个顺序IO。而insert、update、delete都是随机IO。redo type大概有53种。

每逢row id是256的倍数时，就会写入系统表空间第7号页面的某个位置，位于information库的。因为redo type很多，所以redo日志格式会有不同，比如MLOG_8BYTE redo日志格式：

 

举例：在0号表空间（space ID）7号页面（page Number）200的位置（offset）写入一个值1024（data）。每个row id都占据8个字节，因为是对8个字节的修改，所以type是MLOG_8TYPE，如果是修改一个字节，那么就是MLOG_1TYPE等等，MLOG_WRITE_STRING表示修改的是string。

当fsync函数有返回值时，mysql才会确确实实把数据落盘到磁盘上，做持久化了。
show variables like 'innodb_flush_log_at_trx_commit';  --默认值是1，表示当事务提交时，确保redo日志落盘到磁盘。值为2的话，只能保证写到缓冲区，但是日志能不能落盘不保证。值为0的话，事务提交时，不立即提交redo日志，将由后台线程去做，缺点是如果事务提交时，mysql挂了，后台线程来不及同步redo日志，那么将不保证完全的事务持久性。

每一个redo日志都有一个序列号Log Sequence Number 简称LSN。flushed_to_disk_lsn表示已落盘到磁盘上的事务，mysql在恢复数据的时候就是根据这两个LSN的差值来决定事务从哪里开始到哪里结束，所以LSN是非常有用。

崩溃后的恢复为什么不用bin log？ bin log主要用于mysql的主从复制上，主库会把ddl和dml的修改通过网络传递给从库，从库接收后执行。

 

bin log 与redo log有何不同？

1、使用方式不一样。bin log会用于所有的更改操作，主要用于人工恢复数据。而redo log是mysql自己恢复使用的。

2、使用机制不一样。redo log是innodb独有的，bin log是mysql server层实现的，所有存储引擎均可使用bin log。

3、redo 日志所记录的是物理日志，记载的是页面上的某个offset做了什么修改。而bin log是逻辑日志，比如id = 2的字段我做了 +1操作，记录的是原始逻辑。

4、写盘机制不一样。redo log只有两个，循环写，记录的是事务已经提交但是数据尚未落盘的数据，一旦落盘就会从redo log中删除。而bin log是追加日志，保存的是全量修改日志。

5、通过redo日志文件保存内容，可以判断出哪些数据已经落盘。

【undo日志】

如果要进行delete和update操作，我要记录它本来的值，记录下来的信息就是undo日志，是为事务的一致性操作准备的。然后在一堆的undo日志里，需要分配一个事务id，事务可以分为两种，只读和读写，只读事务不可以对普通的用户表，就是create table这些表进行增删改查，但是可以对用户的临时表进行增删改查，比如create tempory table，在事务创建过程中，创建的临时表。

【事务】

begin开始一个事务，只有事务中出现了对表的增删改的时候，才会分配事务ID。delete操作对应的undo日志 TRX_UNDO_DEL_MARK_REC，Page Header里包含Page_Free垃圾链表，delete操作的第一步：在page header里面有个delete mask标记，未删除的标为0，已删除的标为1，会产生一条undo日志，第二步：当事务commit提交之后，便会将该记录放到page free垃圾链表里，这时数据才会被真正删除。这个过程称为合并过程。

【MVCC】Multi-Version Concurrency Control

行格式里有个roll_ptr回滚指针，会指向trx_id事务id，而trx_id又会指向undo log，这样就形成了一个回滚链。MVCC只对普通的select查询生效。

那我们再讲讲MVCC里的版本链：

【版本链】

比如我们要插入一行数据：number(主键) = 1, name = Mark, password = mypassword 那么行存储格式大概如下：

1 （列1值）

myname （列2值）

mypassword （列3值）

trx_id  （事务ID）

roll_ptr （回滚指针）

现在回滚指针指向了insert undo，那么insert undo有一条记录了，此后事务1做了两次update，事务2做了两次update，在都未提交的情况下，就会形成一个版本链：

【Read View】

每个事务都会产生一个Read View，简称RV，RV包含：

m_ids ： 记录生产RV时，活跃的读写事务id列表

min_trx_id :     m_ids 中最小事务id

max_trx_id :    系统中将要分配的下一个id值

creator_trx_id :    生成RV（Read View）的事务id，就是创建RV的事务

假如我们现在有3个事务，那么m_ids = 1,2,3   min_trx_id = 1, max_trx_id = 4, create_trx_id = 0

那么问题来了，访问某条记录时，如何判断记录的某个版本是否可见？（判断规则）

1、如果被访问版本的trx_id属性值与Read View中的create_trx_id相同，表示本条记录是自己这个事务创建的，可见。

2、如果被访问版本的trx_id属性值小于Read View中的min_trx_id值，表示访问到了比活跃事务id最小值还要小，表示不活跃了，表示已经提交了，可见。

3、如果被访问版本的trx_id属性值大于或等于Read View中的max_trx_id值，表示被访问的事务创建时间晚于自己这个事务，所以不能访问，不可见。

4、如果被访问版本的trx_id属性值在Read View的min_trx_id和max_trx_id之间，min_trx_id < trx_id < max_trx_id，就需要判断被访问的trx_id是否还在m_ids活跃事务列表里，如果不活跃了表示事务已提交可访问，如果还在表示事务还在活跃尚未提交不可访问。这个过程就是遍历版本链，一个一个找，看哪个能访问，如果一个都找不到，那么查询结果里这条记录就不可见。

5、如果某个版本的数据对当前事务不可见的话

【判断规则举例】

比如当前Read View事务是这样的： m_ids[80,120]    min_trx_id = 80     max_trx_id = 121    creator_trx_id = 0，而版本链是这样的：

那么对应各个事务隔离级别，mysql将会读取哪一条数据呢？参考《mysql的innodb存储引擎事务隔离级别》我们来一个一个对应：

Read uncommitted    未提交读。只要m_ids活跃事务列表里有数据，就读到了，所以会出现脏读。

Read committed    已提交读。在每次读取数据之前，都会生成一个Read View。因为m_ids事务活跃列表里有80，120两个尚未提交事务，所以会读取到trx_id = 60这个已提交事务行。

Repeatable read   可重复读。只在第一次读取数据时生成一个Read View。因为RV不会变，所以即使在两个update过程中有其它事务已提交，mysql仍然会以旧RV的标准永远只读到相同的那一条记录。

Serializable      可序列化。

【Read Committed 已提交读，很大程度上避免了幻读，但是在某些特殊情况下还是会产生幻读现象，举例】

事务1	事务2
begin;
select * from teacher where number = 35;      -- 没有存在
	begin;
	insert into teacher values(35, 'Mark2', 'ELK');
	commit;
select * from teacher where number = 35;      -- 依然查不到
update teacher set domain = 'mysql' where number = 35;
select * from teacher where number =35;      -- 查到了，出现了幻读！ 那为什么这里出现了幻读？是因为当上一条update sql时的trx_id是本事务id，所以这个值就这样被特殊的读到了。
commit;

 

end.