MySql三大日志

 

重做日志（redo log）

作用：(InnoDB才有)

确保事务的持久性。redo日志记录事务执行后的状态，用来恢复未写入data file的已成功事务更新的数据。

防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

redo log刷盘时机

log buffer的记录需要按照一定的策略被刷新到redo log的磁盘文件中，比如：

• log buffer空间不足

log buffer的大小是有限的（通过系统变量innodb_log_buffer_size指定），如果不停的往这个有限大小的log buffer里塞入日志，很快它就会被填满。

InnoDB认为如果当前写入log buffer的redo日志量已经占满了log buffer总容量的大约一半左右，就需要把这些日志刷新到磁盘上。

• 事务提交时

前边说过之所以使用redo日志主要是因为它占用的空间少，还是顺序写，在事务提交时可以不把修改过的Buffer Pool缓存页刷新到磁盘，但是为了保证持久性，必须要把修改这些页面对应的redo日志刷新到磁盘。

• 后台有一个线程，大约每秒都会刷新一次log buffer中的redo日志到磁盘。

• 正常关闭服务器时等等。

redo log刷盘策略

innodb_flush_log_at_trx_commit 参数
值为 0 表示每次事务提交不刷入磁盘，默认master thread每隔1s进行一次重做日志的同步；

值为 1 表示每次事务提交立即刷入磁盘；

值为 2 表示每次事务提交先刷到 os cache，由os决定什么时候同步到磁盘。

回滚日志（undo log）

作用：

保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读

 

二进制日志（binlog）

记录所有修改数据库的操作

作用：

用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。

Binlog 的格式有 3 种：

• Statement 基于语句，只记录对数据做了修改的SQL语句，能够有效的减少binlog的数据量，提高读取、基于binlog重放的性能
• Row 只记录被修改的行，所以Row记录的binlog日志量一般来说会比Statement格式要多。基于Row的binlog日志非常完整、清晰，记录了所有数据的变动，但是缺点是可能会非常多，例如一条update语句，有可能是所有的数据都有修改；再例如alter table之类的，修改了某个字段，同样的每条记录都有改动。
• Mixed Statement和Row的结合，怎么个结合法呢。例如像alter table之类的对表结构的修改，采用Statement格式。其余的对数据的修改例如update和delete采用Row格式进行记录。