MySQL事务(Transaction)详解（二）——事务日志

一、 序言

针对突然宕机的问题：MySql不会自动继续执行，不会自动直接回滚，但是可以人工手动选择继续执行或者直接回滚，依据是事务日志。

事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是人们口中常说的“日志先行”(Write-Ahead Logging)

为了最大程度避免数据写入时io瓶颈带来的性能问题，MySQL采用了这样一种缓存机制：当query修改数据库内数据时，InnoDB先将该数据从磁盘读取到内存中，修改内存中的数据拷贝，并将该修改行为持久化到磁盘上的事务日志（先写redo log buffer，再定期批量写入），而不是每次都直接将修改过的数据记录到硬盘内，等事务日志持久化完成之后，内存中的脏数据可以慢慢刷回磁盘，称之为Write-Ahead Logging。事务日志采用的是追加写入，顺序io会带来更好的性能优势。

innodb事务日志包括redo log和undo log。
redo log是重做日志，提供前滚操作（即重新操作）
undo log是回滚日志，提供回滚操作。

二、undo log 和 redo log

• 概念
  在数据库系统中，事务的原子性和持久性是由事务日志（transaction log）保证的，在实现时也就是上面提到的两种日志，前者用于对事务的影响进行撤销，后者在错误处理时对已经提交的事务进行重做，它们能保证两点：
  1、发生错误或者需要回滚的事务能够成功回滚（原子性）；
  2、在事务提交后，数据没来得及写会磁盘就宕机时，在下次重新启动后能够成功恢复数据（持久性）；
  在数据库中，这两种日志经常都是一起工作的，我们可以将它们整体看做一条事务日志，其中包含了事务的 ID、修改的行元素以及修改前后的值。
  

• redo log (重做日志)——保障的是事务的持久性和一致性

  为了避免脏数据刷回磁盘过程中，掉电或系统故障带来的数据丢失问题，InnoDB采用事务日志（redo log）来解决该问题。

  在事务 提交之后，数据没有来得及 写入 到 磁盘 的时候，mysql 重启 就会执行 redo log 重做日志

  redo log通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。当事务提交之后，数据从文件刷入磁盘时，发