关注我「程序猿集锦」，获取更多分享。

前言

前面我们介绍了MySQL中的慢查询slow query log，二进制日志binlog，中继日志relay log，重做日志redolog，今天我们来看一下另外一个重要的日志：undo log。

什么是undo log

undo log，就是大家经常所说的回滚日志。

它里面记录的是对数据的回滚操作。当我们对数据库中的数据有变动操作的时候，为了可以回滚到数据被改动之前的版本，就把数据的变动过程的逆向操作给记录在undo log中。我们对数据库的查询查找是不会记录undo log的，只有数据库中的数据有变化的操作才会记录undo log。

undo log的作用

我们执行一个insert语句，在undo log中就记录一个delete语句，用于删除掉刚插入的数据，以此来达到回滚到插入之前的状态；

我们执行了一个update语句，在undo log中也记录一个upate语句，只不过这个update语句的内容是把我们刚才执行update操作的数据内容给修改回去，以此达到回滚到数据修改之前的状态；

我们执行一个delete语句，在undo log中就记录一个insert语句，用于把刚才删除的数据再插入到数据库中，以此来达到回滚到删除之前的状态。

简而言之：undo log中记录的内容是如何把数据还原到变动之前的状态，根据这个日志中的记录，就可以把数据还原到上一个事务提交后的状态。

还用Undo Log来实现多版本并发控制(简称：MVCC)。Undo Log是为了实现事务的原子性。什么是事务的原子性，这里简单提一句：一个事务的所有操作要么全部成功，要么全部失败，不能只提交部分操作。在失败的时候回，需要回滚之前的部分操作，而这个回滚操作就是依赖于我们今天提到的undo log。从undo log里面去回滚数据到事务开启之前的状态。

事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发生了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。

而redolog是为了实现事务的持久性，要把所有对数据的修改，持久化到磁盘，只要事务提交成功了，不能因为重启、宕机等原因导致提交的数据丢失了，不见了。这里，把redo和undo两种log对记一下。

事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。为了保证持久性，数据库系统会将修改后的数据完全的记录到持久的存储上。

undo log的存储空间

MySQL中的数据存放有对应的表空间，日志的存放也有对应的表空间，一个个表空间对应到磁盘上就是一个个数据文件。undolog也有undolog tablespace的概念，但是undolog的表空间在不同的MySQL版本中有一点不一样，接下来分别说明一下。

和系统表空间存放在一起

在MySQL5.6.3之前的版本中，这个undolog table space是和system tablespace系统表空间存放在一起的，如上图中红色框选的部分，因为系统表空间对应的磁盘上面的数据文件就是ibdata1这个文件，所以在MySQL的相关目录下面，我们看不到任何关于undolog相关的数据文件。

独立的undolog表空间

在5.6.3之后的版本中，MySQL支持将undolog tablespace单独剥离出来，不在和系统表空间放在一起，如上图中绿色框选的部分。而控制undolog单独配置表空间的相关参数如下：

mysql> show variables like '%undo%';
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_max_undo_log_size | 104857600 |
| innodb_undo_directory    | ./        |
| innodb_undo_log_truncate | ON        |
| innodb_undo_logs         | 128       |
| innodb_undo_tablespaces  | 4         |
+--------------------------+-----------+
5 rows in set (0.01 sec)

mysql> show variables like 'datadir';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.02 sec)

mysql> show variables like 'innodb_purge_rseg_truncate_frequency';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128   |
+--------------------------------------+-------+
1 row in set (0.02 sec)

mysql> show variables like 'innodb_rollback_segments';/*这个参数是参数innodb_undo_logs的同义词*/
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_rollback_segments | 128   |
+--------------------------+-------+
1 row in set (0.24 sec)

undo log的相关参数

使用独立的undolog表空的时候，会使用如下各个参数：

mysql> show variables like 'innodb_rollback_segments';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_rollback_segments | 128   |
+--------------------------+-------+
1 row in set (0.24 sec)

mysql> show variables like 'innodb_undo_logs';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_undo_logs | 128   |
+------------------+-------+
1 row in set (0.01 sec)

1. 它定义了undo tablespace的表空间文件中包含的回滚段rollback segments的数目。默认值为128，这也是它的最大值，128个回滚段是innodb所能支持的最大的回滚段的数目。官方文档中建议这个值设置为>=35的值，这里说一下为什么。
2. 128个回滚段中，需要32个给临时表空间使用，1个给系统表空间使用，此时为32+1=33个，开启独立表空间之后，我们通常还会开启自动回收回滚表空间的操作，所以至少需要2个独立的表空间文件，此时就是33+2=35。这里就是为什么要设置innodb_undo_logs>=35的原因。建议保持默认的128，如果为128，此时innodb_undo_tablespaces的值就可以设置为最大的值95，其中32个分配给了临时表空间。1个给系统表空间。还剩余128-32-1=95个，这95可以全部给独立的回滚表空间来用。
3. 每一个rollback segments，内部有1024个undo segment 组成。所以，可执行 95*1024 个并发事务操作，每个事务占用一个 undo segment slot，注意，如果事务中有临时表事务，还会在临时表空间中的 undo segment slot 再占用一个 undo segment slot，即占用2个undo segment slot。如果错误日志中有：Cannot find a free slot for an undo log。则说明并发的事务太多了，需要考虑下是否要分流业务。

2021-01-10T20:01:47.079434+08:00 0 [ERROR] InnoDB: Expected to open 95 undo tablespaces but was able to find only 4 undo tablespaces. Set the innodb_undo_tablespaces parameter to the correct value and retry. Suggested value is 4
2021-01-10T20:01:47.079669+08:00 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2021-01-10T20:01:47.695873+08:00 0 [ERROR] Plugin 'InnoDB' init function returned error.
2021-01-10T20:01:47.696568+08:00 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2021-01-10T20:01:47.696825+08:00 0 [ERROR] Failed to initialize builtin plugins.
2021-01-10T20:01:47.697028+08:00 0 [ERROR] Aborting

root@test:/var/lib/mysql# pwd
/var/lib/mysql
root@test:/var/lib/mysql# du -sh undo*
10M	undo001
10M	undo002
10M	undo003
10M	undo004
root@test:/var/lib/mysql#

独立undolog表空间的意义

我们思考一下：为什么要支持把undolog的tablespace单独剥离出来呢？

这是从性能的角度来考量的。原先的undolog和系统表空间共享一个表空间，这样在记录undolog的时候，和其他的一些使用系统表空间来存储的操作肯定会存在磁盘I/O的竞争。但是如果我们把undolog的表空间单独拉出来，支持让其自定义目录和表空间的数量，这样我们可以把undolog配置单独的磁盘目录，提高undo log日志的读写性能。

从另外一个方面，在5.6.3之前的MySQL版本中，undolog存放在系统表空间中，此时的undo log是无法自动收缩清除，如果有大事务或长事务的存在，就可能导致undulog日志文件越来越大，这就会使磁盘空间使用越来越大，数据库的上线时间越长，这个系统表空间有越来越大，有时候设置导致ibdata1这个文件达到20多个GB，这样导致备份数据库也会越来越长。如果此时我们想回收undulog日志文件的大小，只能把整个库备份后删除重建，然后再把备份的数据导入到新的数据库实例中去。

所以在MySQL的生产环境中，建议配置独立的undolog表空间。一般的配置如下所示：

[mysqld]
# undolog回滚表空间的配置
innodb_max_undo_log_size = 1G
innodb_undo_directory = /data/mysql/undolog
innodb_undo_log_truncate = ON
innodb_undo_logs = 128
innodb_undo_tablespaces = 8
innodb_purge_rseg_truncate_frequency = 128

最后

undolog回滚日志就写到这里了，后面会分享MySQL的一般查询日志和错误日志。