数据库篇：mysql日志类型之 redo、undo、binlog

可以说mysql的多数特性都是围绕日志文件实现，而其中最重要的有以下三种

innodb 为了提高磁盘I/O读写性能，存在一个 buffer pool 的内存空间，数据页读入会缓存到 buffer pool，事务的提交则实时更新到 buffer pool，而不实时同步到磁盘（innodb 是按 16KB 一页同步的，一事务可涉及多个数据页，实时同步会造成浪费，随机I/O）。事务暂存在内存，则存在一致性问题，为了解决系统崩溃，保证事务的持久性，我们只需把事务对应的 redo 日志持久化到磁盘即可（redo 日志占用空间小，顺序写入磁盘，顺序I/O）

sql 语句在执行的时候，可能会修改多个页面，还会更新聚簇索引和二级索引的页面，过程产生的redo会被分割成多个不可分割的组（Mini-Transaction）。MTR怎么理解呢？如一条 insert 语句可能会使得页分裂，新建叶子节点，原先页的数据需要复制到新数据页里，然后将新记录插入，再添加一个目录项指向新建的页子。这对应多条 redo 日志，它们需要在原子性的 MTR 内完成

MTR 产生的 redo 日志先会被复制到一个 log buffer 里(类似 buffer pool)。而同步到磁盘的时机如下：

事务需要保证原子性，也是说事务中的 *** 作要么全部完成，要么什么也不做。如果事务执行到一半，出错了怎么办-回滚。但是怎么回滚呢，靠 undo 日志。undo 日志就是我们执行sql的逆 *** 作

binlog有三种格式：Statement、Row以及Mixed。

redolog 中的事务如果经历了二阶段提交中的prepare阶段，则会打上 prepare 标识，如果经历commit阶段，则会打上commit标识（此时redolog和binlog均已落盘）。崩溃恢复逻辑如下：

MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。

binlog是Mysql sever层维护的一种二进制日志，与innodb引擎中的redo/undo log是完全不同的日志；其主要是用来记录对mysql数据更新或潜在发生更新的SQL语句，并以"事务"的形式保存在磁盘中；

Mysql binlog日志有ROW,Statement,MiXED三种格式：

有 statement,row, mixed3种,其中mixed是指前2种的混合.

以insert into xxtable values (x,y,z)为例,

影响: 1行,且为新增1行, 对于其他行没有影响.

这个情况,用row格式,直接复制磁盘上1行的新增变化.

这个情况,一般也只是影响1行. 用row也比较合适.

以过年发红包,全公司的人,都涨薪100元.

这个语句带来的影响,是针对每一行的, 因此磁盘上很多row都发生了变化.

此处,适合就statment格式的日志.

2种日志,各有各的高效的地方,mysql提供了mixed类型.

可以根据语句的不同,而自动选择适合的日志格式.

undo日志用于存放数据修改被修改前的值，假设修改 tba 表中 id=2的行数据，把Name='B' 修改为Name = 'B2' ，那么undo日志就会用来存放Name='B'的记录，如果这个修改出现异常，可以使用undo日志来实现回滚 *** 作，保证事务的一致性。

对数据的变更 *** 作，主要来自 INSERT UPDATE DELETE，而UNDO LOG中分为两种类型，一种是 INSERT_UNDO（INSERT *** 作），记录插入的唯一键值；一种是 UPDATE_UNDO（包含UPDATE及DELETE *** 作），记录修改的唯一键值以及old column记录。

---