mysql undolog redolog binlog 的区别

首先说下undolog：

      undo log的主要作用是用作事务的回滚和实现mvcc功能，因为mvcc的问题，需要对undolog随机读

      user表中原纪录为

 

id	name
1	xiaoming

 

　　这个时候执行一个sql    update user set name = 'xiaohong' where id = 1;   这个时候生成的undolog是逻辑变更，大概是update user set name = 'xiaoming' where id = 1

　　undolog用来保证事务的一致性，在事务回滚的时候会查询对应的undolog，进行回滚。

      undolog分为两种，一种是insert undolog，这种是插入语句对应的的undo log，他不会被作为mvcc，于是在提交之后这个log直接释放。

      还有另外一种就是update undolog 这种是会以用于mvcc的，于是这种undolog 是会用链表串起来的，知道没有开启的事务早于当前undolog的创建时间，这个时候这个undolog就可以删除了

 

redolog

redolog用来保证事务的原子性和持久性

数据库运行阶段不需要读redolog进行读取。 所有线程公用一份redolog  buffer。 在事务执行期间，redolog是记录在redolog buffer中的

innodb_flush_log_at_trx_commit参数会决定redo log刷盘的频率，如果是设置为1，那么每次commit都会刷盘（最好设置成这样），innodb master会每秒调用 write 写到文件系统的 page cache，然后调用 fsync 持久化到磁盘。

还有两种情况是会主动刷盘:

1、redolog buffer占用超过innodb_log_buffer_size的一半，就会write到page cache中

2、事务提交的时候会把redo log buffer持久化到磁盘

 

因为两阶段提交是  redo log 先 prepare， 再写 binlog，最后再把 redo log commit

所以redo log 在 prepare阶段 就要先write并fsync

 

redolog  buffer在提交的时候里面可能包含了多个事务的redolog，所以一次性fsync的事务越多越好，那么就有了一个优化

 

 这里的红色块是在一个队列中，头trx是事务，然后会遍历redolog  buffer进行write，然后由leader进行fsync

我们理解的事务两阶段提交是  redolog prepare -> binlog 写入磁盘 -> redolog commit

redolog prepare 的时候需要写redolog，其实分为两步 redolog wirte和redolog fsync

binlog的写盘也是分为两步 binlog wirte 和 binlog fsync

所以最终你以为的事务提交过程是    redolog wirte -> redolog fsync -> binlog wirte -> binlog fsync

但是实际上这里做了一个优化，就是redolog希望尽可能晚的进行组提交， 就可以减少fsync的次数

 

binlog 其实是数据库server层的日志，一般用作主从同步和数据恢复，数据格式有statement、row、还有mixed

statement是sql格式的，row记录了行的变更（从什么到什么），mixed是这两种的混合形式

binlog是在两阶段提交 preparre 和 commit之间，也是要先write到page cache（文件系统缓冲区），然后调用fsync进行刷盘