日志系统 - redo log - binlog

查询流程的执行过程一般是经过连接器、分析器、优化器、执行器、存储引擎。

更新流程也是类似，不同的是更新流程会涉及到两个重要的日志模块 redo log（物理日志） 和 binlog（逻辑日志）。

 

reco log

对于更新，mysql用的是WAL技术（Write-Ahead Logging），关键点就是先写日志，然后再写磁盘。

具体来说，当有一条记录需要更新的时候，InnoDB引擎会先记录到redo log中，并更新内存。同时InnoDB引擎会在适当的时候把记录更新到磁盘中。redo log在InnoDB中是有固定大小的，当写日志的时候会从头开始写，写到末尾又要回到开头循环写，当遇到日志写满 ，InnDB会未及时更新到磁盘时，这时候不会再执行新的更新操作，会推进更新到磁盘的操作。有了redo log，InnoDB就可以保证即使数据库发生异常启动，之前提交的记录都不会丢失，这个能力称之为crash-safe。

 

binlog

mysql整体主要分为两层：1.server层，只要是mysql功能层面  2.引擎层，负责存储相关

redo log 是InnoDB引擎特有的日志，binlog 是server层的日志。最开始mysql里面是没有InnoDB引擎，MyISAM是没有crash-safe的能力，InnoDB是另一个公司以插件形式引入mysql的,所以它使用了另一套日志系统redo log来实现。

 

两个日志文件的区别：

1. redo log是InnoDB引擎独有的；binlog是mysql server层实现的，所有引擎都拥有。

2. redo log是物理日志，主要记录“在某个数据页面做了什么修改”；binlog是逻辑日志，记录语句的原始逻辑，比如”把c字段的某个值a改成了b"

3. redo log 是循环写的，空间固定会用完；binlog是可以追加写入的，到一定大小后会重新写一个文件，不会覆盖前文件

 

两阶段提交：

两阶段的目的是为了让两份日志之间的逻辑一致。update更新的时候 InnoDB会先把新数据更新到内存，写入redolog（当前为prepare阶段，还未提交），然后再写入 binlog，最后提交事务（redo log为commit阶段，此刻才算提交）。

如果不采用两阶段提交，采用直接写完redo log 再写binlog 会怎么样？

情况一：先写redo log再写binlog。redo log写完 binlog 还没写完，mysql进程异常启动，因为redo log存在仍旧能够把数据恢复，但是binlog里面没有记录这个语句，因此备份日志里面binlog就没有这条语句，用binlog来恢复数据就会不同。

情况二 ：先写binlog 后写redo log。如果在binlog写完后crash，redo log并没有记录，数据无法恢复但是binlog里面会多出一个事物，与原库值不同。

 

优化点：

1.innodb_flush_log_at_trx_commit 参数设置成1 表示每次事物的redo log 都可以直接持久化到磁盘，这样可以保证mysql异常重启数据不会丢失。

2.sync_binlog 参数设置成1 表示每次事物的binlog都可以直接持久化到磁盘，这样可以保证mysql异常重启后binlog不会丢失。