Mysql日志

Redo log（Innodb存储引擎的日志文件）

redo log通常是物理日志，记录的是数据页的物理修改，用来恢复提交后的数据页，且只能恢复到最后一次提交的位置，即前滚。redo log保证了Mysql的持久性（Durability）。

Redo log的运行原理

redo log分为两部分，一是内存中的缓冲日志（redo log buffer），该部分是易失性的，二是磁盘上的重做日志（redo log file），该部分是持久的。

当事务提交的时候，Innodb存储引擎会先把日志写入内存中缓冲区(redo log buffer),然后写入到OS Buffer，此时事务就算是结束了，然后Innodb会在合适的时机将日志同步（fsync）到磁盘中的redo log file中，这时，就算数据库发生异常重启，Mysql也会从redo log file中将数据恢复，保证了事务的Durability。
ps：redo log file是固定大小的， 是一个循环写的过程

Mysql提供了三种方式将redo log buffer中日志刷到redo log file，可以通过设置innodb_flush_log_at_trx_commit来决定

当设置为0时，事务提交时不会将log buffer中的日志写入到os buffer，而是每秒写入os buffer并调用fsync()同步到log file中。如果系统崩溃，会丢失1秒钟的数据。
当设置为1时，事务提交时会直接将log buffer中的日志写入到os buffer，同时调用fsync()同步到log file中。这种方式，即使系统崩溃，也不会发生数据丢失，但是IO性能较差。
当设置为2时，事务提交时会直接将log buffer中的日志写入到os buffer，然后每秒调用一次fsync()同步到log file中。如果系统崩溃，也会丢失1秒钟的数据。

Undo log（Innodb存储引擎的日志文件）

undo log是逻辑日志，记录的是在事务中操作数据前，将数据先备份到undo log中，然后再进行数据的修改，如果出现了错误或者rollback，Mysql可以利用undo log中的记录将数据恢复到事务开始前的状态，也就是回滚，undo log保证了事务的原子性(Atomicity)。

Undo log的运行机制

1.insert：undo log中会记录一条对应的delete记录
2.delete：实际上不会删除，而是将delete对象打上delete flag标记为删除。
3.update：在undo log中直接反向记录是如何update的。

binlog(server层的日志文件)

binlog(二进制日志)是server层的日志，binlog中会记录所用的逻辑，并且采用追加写的方式。

binlog和redo log的区别

1.redo log是Innodb独有的，binlog是所有存储引擎都可以使用的
2.redo log是物理日志，记录的是在某个数据页上做了什么修改，binlog是逻辑日志，记录的是这条语句的原始逻辑
3.redo log是循环写的，空间会用完，binlog是可以追加写的，并且不会覆盖之前的日志信息

数据更新的流程

1.执行器先从引擎中找到数据，如果在内存中则直接返回，如果不在内存中，查询后返回。
2.执行器拿到数据后对数据进行更新，然后调用引擎接口重新吸入数据。
3.引擎将数据更新到内存，同时写入redo log，此时redo log处于prepare阶段，并通知执行器执行完成
4.执行器生成这个操作的binlog
5.执行器调用引擎的事务提交接口，引擎把刚刚写完的redo log改成commit状态，更新完成。