mysql事务（一）——redo log与undo log

数据事务

即支持ACID四大特性。

A：atomicity          原子性——事务中所有操作要么全部执行成功，要么全部执行失败，回滚到初始状态

C：consistency     一致性——数据库总是从一个一致性状态变化到另一个一致性状态

I：isolation            隔离性——一个事务所做的操作在事务提交前是否被另外一个事务可见，mysql可配置，用以适用不同场景

D：durability         持久性——事务一旦提交，所做操作永久保存（不是仅仅在内存中修改）

mysql通过redo log和undo log保障事务

redo log

事务中所有操作会先写到redo log中，然后再同步到数据库文件中。所以数据库文件进行事务操作修改时，redo log肯定已经记录了所有事务操作，此时即使数据库挂掉，事务操作也都已经持久化到redo log中了，数据库恢复后可以继续执行剩下操作。

redo log有两部分组成，redo log buffer与redo log file。如果每个事务的redo log都实时写到file中，再写到数据文件中，那么性能会比较差，所以可以先把一定时间间隔中的事务操作记录到buffer中，然后统一刷新到file中（此时数据库文件的刷新不一定晚于重做日志文件的刷新）。

redo log使用buffer缓存，丢失了数据持久性，数据库宕机时，没有持久化到redo log file中的事务操作也会丢失。此时数据库数据需要回滚到这些丢失事务之前的状态，undo log正好记录了事务之前的状态。

redo log是物理日志，记录里的是对数据库页的操作，不是sql语句，具有幂等性。

log group包含多个redo log，redo log循环覆盖log group中的文件。

undo log

undo log记录了事务提交之前的数据状态。所以当事务操作同步到数据文件仅仅执行了一半就失败了，恢复后无法找到剩余事务操作，那就只好回滚到事务执行前了。这是就可以使用undo log了。

不同于redo log存放在单独文件中，undo log存放在数据库内部特殊的段中（undo segment），这个段位于共享表空间中。可以知道，undo log必然发生在事务执行之前，所以事务操作执行开始了，undo log必然已经存在了。

redo log与binlog的区别

mysql只有innodb支持事务，redo log和undo log都是innodb的产物。binlog也可以用作数据恢复，不过它是整个mysql的日志，对于所有存储引擎都生效。

binlog存储的是逻辑sql，这一点与redo log中的物理格式不同。

binlog在事务结束后才写进文件，redo log在事务执行中写进文件。

redo log参数设置

执行show global variables like '%innodb%log%';查看参数

1、innodb_log_file_size：redo log大小，单位字节

2、innodb_log_files_in_group：redo log group大小，日志组中存在多少个redo log文件

3、innodb_log_group_home_dir：redo log路径，上图表示同数据文件路径

4、innodb_log_buffer_size：重做日志缓存大小

5、innodb_flush_log_at_trx_commit：事务从redo log buffer刷新到redo log file策略

默认值为1，表示redo log事务提交时，立即将操作从buffer刷入file中（commit ->redo log buffer->os buffer->redo log file）。

0表示每innodb_flush_log_at_trx_commit秒钟将redo log buffer刷入redo log file一次。数据库宕机，最多丢失innodb_flush_log_at_trx_commit秒操作。

2表示每次事务提交，都会将redo log buffer写入os buffer，每innodb_flush_log_at_trx_commit秒钟将os buffer同步到redo log file中。这种情况下，数据库宕机，服务器没有宕机，数据库恢复后，已经写入os buffer的事务操作还可以写到redo log file中。

6、innodb_flush_log_at_timeout：配合innodb_flush_log_at_trx_commit使用，表示redo log多久从buffer刷入file中。