InnoDB当您使用 SQL 语句删除行时，它不会立即从数据库中物理删除行。InnoDB只有在丢弃为删除而写的撤销日志记录时，一行及其索引记录才会被物理 删除。此删除操作仅在多版本并发控制 (MVCC) 或回滚不再需要该行之后发生，称为清除。

清除按定期计划运行。它从历史列表中解析和处理撤消日志页，历史列表是 InnoDB事务系统维护的已提交事务的撤消日志页列表。Purge 在处理完撤消日志页面后将其从历史列表中释放。

配置清除线程

清除操作由一个或多个清除线程在后台执行。清除线程的数量由 innodb_purge_threads变量控制。默认值为 1。如果 DML 操作集中在单个表上，则表的清除操作由单个清除线程执行。如果 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 施加延迟 ，以便清除操作有时间赶上。默认值为 0，这意味着没有最大清除滞后且没有延迟。 INSERTUPDATEDELETE

事务系统维护一个事务列表，这些InnoDB事务具有由 UPDATE或 DELETE操作标记为删除的索引记录。列表的长度是清除滞后。清除滞后延迟由以下公式计算得出，最小延迟为 5000 微秒：

(purge lag/innodb_max_purge_lag - 0.5) * 10000

延迟是在清除批次开始时计算的。

有问题的工作负载的典型innodb_max_purge_lag 设置可能是 1000000（一百万），假设事务很小，大小只有 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增加的长时间运行事务的示例：

为了防止在清除延迟变得巨大的极端情况下出现过度延迟，您可以通过设置 innodb_max_purge_lag_delay 变量来限制延迟。该 变量指定超过阈值innodb_max_purge_lag_delay 时施加的延迟的最大延迟（以微秒为单位 ）。innodb_max_purge_lag指定 innodb_max_purge_lag_delay值是通过公式计算的延迟时间的上限 innodb_max_purge_lag。