回滚日志（Undo Log） 的 Purge
一、undo log的purge机制
- 什么是undo log的purge？
Undo log的purge是指在数据库系统中，对已经不再需要的undo log记录进行清理和回收的过程。
- 是不是事务一提交就会把undo log purge？
当事务提交后，其对应的undo log并不会立即被清理。只有当系统确定没有其他事务再需要这些undo log时，才会进行purge操作。这意味着undo log的生命周期可能比事务的生命周期更长。
二、怎么判断undo log可以被purge？
在数据库系统中，判断undo log是否可以被purge，主要依据以下几点：
-
事务提交和undo log的状态：当事务提交后，其对应的undo log并不会立即被清理。只有当系统确定没有其他事务再需要这些undo log来维护读一致性时，才会进行purge操作。
-
事务的提交顺序（trx_no）：每个写事务结束时都会获得一个递增的编号（trx_no）作为事务的提交序号。而每个读事务会在自己的ReadView中记录开始时看到的最大trx_no为m_low_limit_no。如果一个事务的trx_no小于当前所有活跃的读事务ReadView中的m_low_limit_no，说明该事务在所有读开始之前已经提交，其修改的新版本是可见的，因此不再需要通过undo构建之前的版本，这个事务的undo log就可以被清理了。
-
undo log的类型：对于不同类型的undo log记录，判断是否可以被清理的方式也有所不同。例如，TRX_UNDO_DEL_MARK_REC类型的undo record对应的记录需要从索引上真正删除后，其对应的undo log才可以被清理。
-
undo log的生命周期管理：undo log的生命周期可能比事务的生命周期更长，因为它们可能被其他事务用于维护读一致性。只有当所有可能需要这些undo log的事务都完成之后，它们才可以被清理。
-
purge queue的使用：系统会维护一个purge queue，其中按照事务提交顺序（trx_no）排序，确保先提交的事务对应的undo log先被处理。purge线程会按照这个顺序依次处理undo log，判断哪些记录已经不再需要。
三、Undo log purge的优化
1、调整purge线程数
show global variables like "innodb_purge_threads";通过增加Purge线程数量，可以加快Purge操作的执行速度。默认情况下，Purge线程数为4，但可以根据服务器的负载和CPU核心数进行调整。例如，如果服务器的CPU资源较为充裕，且负载较高，可以适当增加Purge线程数，如设置为8。
2、设置purge延迟
innodb_purge_rseg_truncate_frequency 是 MySQL 中用于控制 Purge 系统释放回滚段频率的变量，其默认值为 128，表示 Purge 线程每被调用 128 次，就会释放一次回滚段。
该变量的取值范围为 1 到 128，数值越小，Purge 线程释放回滚段的频率越高。当需要加快 Undo 表空间的截断时，可以通过减小该值来实现。
3、监控事务状态
show processlist;
select * from information_schema.innodb_trx;