InnoDB当您使用 SQL 语句删除某行时，它不会立即从数据库中物理删除该行。InnoDB仅当丢弃为删除而写入的撤消日志记录时，才会物理删除行及其索引记录 。这种删除操作仅在多版本并发控制 (MVCC) 或回滚不再需要该行之后发生，称为清除。
清除定期运行。它解析和处理历史列表中的撤消日志页面，历史列表是由 InnoDB事务系统维护的已提交事务的撤消日志页面列表。清除处理后从历史列表中释放撤消日志页面。
配置清除线程
清除操作由一个或多个清除线程在后台执行。清除线程的数量由 innodb_purge_threads变量控制。默认值为 4。
如果 DML 操作集中在单个表上，则表的清除操作由单个清除线程执行，如果 DML 操作涉及较大的对象值，这可能会导致清除操作变慢、清除延迟增加和表空间文件大小增加。从 MySQL 8.0.26 开始，如果 innodb_max_purge_lag超出设置，清除工作会自动在可用的清除线程之间重新分配。在这种情况下，过多的活动清除线程可能会导致与用户线程的争用，因此请 innodb_purge_threads相应地管理设置。该 innodb_max_purge_lag变量默认设置为 0，这意味着默认情况下没有最大清除滞后。
如果 DML 操作集中在少数表上，请将 innodb_purge_threads设置保持在较低水平，以便线程不会相互争用对繁忙表的访问。如果 DML 操作分布在许多表中，请考虑更高的 innodb_purge_threads设置。清洗线程的最大数量为 32。
该innodb_purge_threads设置是允许的最大清除线程数。清洗系统会自动调整使用的清洗线程数。
配置清除批量大小
该innodb_purge_batch_size 变量定义了从历史列表中清除一批解析和处理的撤消日志页面的数量。默认值为 300。在多线程清除配置中，协调器清除线程除以 innodb_purge_batch_size该 innodb_purge_threads页数并将其分配给每个清除线程。
清除系统还释放不再需要的撤消日志页面。它通过撤消日志每 128 次迭代执行一次。除了定义批量解析和处理的撤消日志页面的数量外，该 innodb_purge_batch_size变量还定义了撤消日志页面的数量，该数量通过撤消日志每 128 次迭代清除一次。
该innodb_purge_batch_size 变量用于高级性能调整和实验。大多数用户不需要更改 innodb_purge_batch_size其默认值。
配置最大清除滞后
该innodb_max_purge_lag变量定义了所需的最大清除滞后。当清除滞后超过innodb_max_purge_lag 阈值时，会对 、 和 操作施加延迟，以留 INSERT出 UPDATE时间 DELETE让清除操作赶上。默认值为 0，这意味着没有最大清除延迟和延迟。
InnoDB事务系统维护一个事务列表，这些事务的索引记录由 或UPDATE操作 DELETE删除标记。列表的长度是清除滞后。在 MySQL 8.0.14 之前，purge lag 延迟由以下公式计算，导致最小延迟为 5000 微秒：
(purge lag/innodb_max_purge_lag - 0.5) * 10000
从 MySQL 8.0.14 开始，purge lag 延迟通过以下修改后的公式计算，将最小延迟降低到 5 微秒。5 微秒的延迟更适合现代系统。
(purge_lag/innodb_max_purge_lag - 0.9995) * 10000
延迟是在清除批次开始时计算的。
有问题的工作负载的典型innodb_max_purge_lag 设置可能是 1000000（100 万），假设事务很小，只有 100 字节大小，并且允许有 100MB 的未清除表行。
清除滞后在输出 部分显示为History list length值。 TRANSACTIONSSHOW ENGINE INNODB STATUS
mysql> SHOW ENGINE INNODB STATUS;
...
------------
TRANSACTIONS
------------
Trx id counter 0 290328385
Purge done for trx's n:o < 0 290315608 undo n:o < 0 17
History list length 20
通常History list length是一个较低的值，通常小于几千，但是写入繁重的工作负载或长时间运行的事务可能会导致它增加，即使对于只读事务也是如此。长时间运行的事务会导致History list length增加的原因是在一致的读取事务隔离级别下，例如 REPEATABLE READ，事务必须返回与创建该事务的读取视图时相同的结果。因此， InnoDB多版本并发控制 (MVCC) 系统必须在撤消日志中保留数据的副本，直到依赖于该数据的所有事务都完成为止。以下是可能导致History list length增加的长期运行事务的示例：
- 在存在大量并发 DML 时 使用该 选项 的mysqldump操作。
--single-transaction SELECT禁用后 运行查询autocommit，忘记发出明确的COMMITorROLLBACK。
为了防止在清除滞后变得很大的极端情况下出现过度延迟，您可以通过设置 innodb_max_purge_lag_delay 变量来限制延迟。该 变量指定超过阈值innodb_max_purge_lag_delay 时施加的延迟的最大延迟（以微秒为单位 ）。innodb_max_purge_lag指定 innodb_max_purge_lag_delay值是公式计算的延迟时间的上限 innodb_max_purge_lag。
清除和撤消表空间截断
清除系统还负责截断撤消表空间。您可以配置该 innodb_purge_rseg_truncate_frequency 变量来控制清除系统查找撤消表空间以截断的频率。有关详细信息，请参阅 截断撤消表空间。
