mysql的事务日志

一、事务日志

• innodb通过force log at commit机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化。

• 事务日志是连续的磁盘空间，因此IO是顺序的，性能比较高，可以保证数据及时写入事务日志。innodb是使用日志来减少提交事务时的开销。

二、事务日志类型

• redo log：重做日志，提供前滚操作。通常是物理日志，记录的是数据页的物理修改，用于恢复提交后的物理数据页
• undo log：回滚日志，提供回滚操作。通常是逻辑日志，根据每行记录进行记录，用于回滚到某行记录的某个版本

三、redo log介绍

• 当实例或介质失败时，innodb存储引擎会使用日志恢复到停电前的时刻，以此来保证数据的完整性
  每个innodb存储引擎至少有1个重做日志文件组，每个文件组下至少有2个重做日志文件，默认是ib_logfile0和ib_logfile1。

• 重做日志文件不能设置太大，如果设置得很大，在恢复时间可能需要很长的时间；另一方面又不能设置太小，否则可能导致一个事务的日志需要多次切换重做日志文件，从而导致频繁地发生async checkpoint，导致性能的抖动。

1）redo log组成部分

• 内存中的日志缓冲（redo log buffer）
• 磁盘上的重做日志文件（redo log file），即ib_logfileN文件

2）redo log日志文件介绍

1. redo log不是二进制日志，是在innodb层产生的，只记录innodb存储引擎中表的修改。而二进制日志是在存储引擎的上层产生，对所有存储引擎都适用。其次，二进制日志先于redo log被记录。
2. redo log是在物理格式上的日志，它记录的是数据库中的每个页的修改。
3. redo log在数据准备修改前写入缓存中的redo log中，然后再对缓存中的数据执行修改操作。

## 查看是否是独立空间
show variables like 'innodb_file_per_table';

## 查看相关参数设置
show variables like 'innodb%log%';

- innodb_log_file_size:每个重做日志文件的大小 
- innodb_log_fileso_in_group:指定日志文件组中重做日志文件的大小
- innodb_mirrored_log_groups:指定日志镜像文件组的数量，默认1，表示没有镜像
- innodb_log_group_home_dir:指定了日志文件组所在路径，默认./

3）innodb_flush_log_at_trx_commit参数介绍

innodb_flush_log_at_trx_commit：只是控制commit动作是否刷新log buffer到磁盘

• 0:事务提交时不会将log buffer中日志写入到os buffer,而是每秒写入os buffer并调用fsync()写入log file on disk中。当系统崩溃后会丢失1秒钟的数据。
• 1:事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。系统崩溃时不会丢失任何数据，但是由于每次提交都写入磁盘，IO性能较差。
• 2:每次提交都会写入到os buffer，然后每秒调用fsync()将os buffer中的日志写入到log file on disk。

PS： 保证事务的ACID中的持久性，必须将innodb_flush_log_at_trx_commit设置为1

4）sync_binlog参数介绍

• 0:当事务提交之后，mysql不控制binlog的刷新，由文件系统自己控制缓存的刷新，或者cache满的时候自动刷新。性能最好，风险最大，系统crash时binlog_cache中所有binlog信息都会被丢失。

• n:当每进行n次事务提交之后，mysql将进行一次fsync之类的磁盘同步命令来将binlog_cache中的数据强制写入磁盘。安全性最高，但是性能损耗最大。系统crash或断电的情况下，系统才有可能丢失1个事务的数据。

PS： sync_binlog设置为0和设置为1的系统写入性能差距可能高大5倍甚至更多。

四、undo log介绍

undo log有两个作用：提供回滚和多个行版本控制(MVCC)

1）undo log的存储方式

• rollback segment称为回滚端，每个回滚端中有1024个undo log segment。undo log是采用段（segment）方式来记录的，每个undo操作在记录的时候占用一个undo log segment。

• undo log默认存放在共享表空间中

• undo log也会产生redo log,因为undo log也要实现持久性保护

2）delete/update操作的内部机制

a.delete操作

• 当事务提交的时候，innodb不会立即删除undo log，因为后续还可能会用到undo log,如隔离级别为repeatable read时，事务读取都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。

b.update操作

• 如果不是主键，在undo log中直接反向记录如何update的，即update是直接进行的。
• 如果是主键列，update分两部分执行，先删除该行，再插入一行目标行。

参考文档：https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html