binlog redo log MVCC
binlog redolog MVCC
- binlog：服务层生产日志，数据恢复、数据库复制
- redo log：数据在物理层面的修改，断电恢复、保证一致性和持久性，顺序 ：写入数据->redo log buffer->file system buffer->fsync操作->redo log file ->commit
binlog格式
在MySQL5.1之前，所有的binlog都是基于SQL语句级别的。但是应用这种格式的binlog进行数据恢复时，如果SQL语句带有rand或uuid等函数，可能导致恢复出来的数据与原始数据不一致。因此从5.1版本开始，MySQL引入了binlog_format参数，该参数有三种可选值：statement、row和mixed：
- statement就是之前的格式，基于SQL语句来记录
- row记录的则是行的更改情况，可以避免之前提到的数据不一致的问题
- 但是row格式有一个不好的地方就是当修改的行数很多时，生成的binlog占用很大的空间，占用大量空间的同时还会耗费大量IO资源，因此MySQL又提供了一种折中的方案——mixed。在mixed模式下，MySQL默认仍然采用statement格式进行记录，但是一旦它判断可能会有数据不一致的情况发生，则会采用row格式来记录
https://www.jianshu.com/p/907f9002442e
redo log，也就是重做日志
事实上这就是我们接下来要讲的redo log，也就是重做日志，它是InnoDB引擎特有的，记录了InnoDB引擎下的事务日志。
redo log作用
同样，我们首先要搞明白的是，已经有binlog了，为什么还需要redo log。
因为两者分工不同。binlog主要用来做数据归档，但是它并不具备崩溃恢复的能力，也就是说如果你的系统突然崩溃，重启后可能会有部分数据丢失，而redo log的存在则可以完美解决这个问题。
redo log记录的是对数据页更改的物理日志，比如类似「将第8页、第1行、第6个位置改成666」这种
-
功能不同，binlog主要用于归档，而redo log主要用于崩溃恢复
-
内容不同，binlog是逻辑日志，而redo log是物理日志
-
写入时机不同，binlog是server层记录的，所有存储引擎可共享，而redo log是InnoDB引擎特有的
-
写入方式不同，binlog容量无限，追加写入，而redo log容量有限，循环写入
补充：
1.MVCC手段只适用于Msyql隔离级别中的读已提交（Read committed）和可重复读（Repeatable Read）.
2.Read uncimmitted由于存在脏读，即能读到未提交事务的数据行，所以不适用MVCC.
原因是MVCC的创建版本和删除版本只要在事务提交后才会产生。
3.串行化由于是会对所涉及到的表加锁，并非行锁，自然也就不存在行的版本控制问题。
4.通过以上总结，可知，MVCC主要作用于事务性的，有行锁控制的数据库模型。
Undo log是MySQL Innodb引擎的日志的一种，记录了老版本的数据。
Undo log是Innodb MVCC重要组成部分，InnoDB的MVCC就是基于Undo log实现的。
当我们对数据进行操作的时候，就会产生undo记录，Undo记录默认记录在系统表空间（ibdata）中，从MySQL 5.6开始，Undo使用的表空间可以分离为独立的Undo log文件。
https://blog.csdn.net/w2064004678/article/details/83012387
https://blog.csdn.net/linshenyuan1213/article/details/81948964
