MySQL运维18-Undo日志

1、Undo日志的内容

• undo日志保存了被活动事务更改的数据的副本（前像），如果另一个事务需要查看原来的数据（例如，满足一致性读），那么可以从undo日志中获得更改之前的数据。默认情况下，undo日志保存在InnoDB系统表空间内，但也可以把undo日志放到独立的数据文件里。

2、Undo日志的作用

1. 查询一致性：undo里保存了数据的前像，从而支持查询的一致性，
2. 灾难恢复：在灾难恢复过程中，它也扮演了重要的角色，它的主要功能是在灾难恢复过程中回滚那些没有提交的变更。

3、长事务对Undo日志的影响

如果在repeatable read事务隔离级别的一个事务长时间未提交，InnoDB不会去清理旧的行版本（old row versions），因为未提交的事务仍然需要看到它。当这个事务一直保持打开而不提交，就可能会导致大量旧的版本数据无法删除，从而导致undo日志暴涨，将系统表空间撑大。

4、Undo日志状态的查看

通过命令SHOW INNODB STATUS的输出，可以看到当前有多少没有被清理的记录。对比下面的Purge done for trx和Trx id counter，如果差异很大，则可能是因为大量事务所导致，也可能是操作大量数据的个别事务所导致的。

------------
TRANSACTIONS
------------
Trx id counter 0 80157601
Purge done for trx’
s n:o <0 80154573 undo n:o <0 0

5、Undo日志的参数配置及优化

• innodb_max_purge_lag参数：InnoDB会用清理线程清理用不到的Undo日志，但如果数据写操作很频繁，清理线程的速度可能跟不上写操作的速度，从而导致undo日志越来越大，可以通过设置innodb_max_purge_lag参数，来避免InnoDB表空间的过分增大。InnoDB事务系统维持了一个事务列表，该列表记录被UPDATE或DELETE操作标志为删除的索引记录。这个列表的长度为purge_lag。当purge_lag超过innodb_max_purge_lag之时，每个INSERT、UPDATE和DELETE操作都将被延迟一定的时间，比如我们可以将其设置为100万。即允许有100万条未清理的记录，在达到100万的阈值后，就会触发延迟其他的写操作。

6、总结

1. InnoDB的Undo日志的作用是保存被当前在途事务修改的数据的前像，从而提供数据查询的一致性和灾难恢复功能。
2. Undo日志默认保存在系统表空间数据文件里，也可以保存到独立的表空间文件里。
3. 当出现大量写操作事务或长事务时，容易导致Undo日志过大，从而撑大系统表空间数据文件。