Documentation Home
MySQL 8.4 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 39.8Mb
PDF (A4) - 39.9Mb
Man Pages (TGZ) - 257.9Kb
Man Pages (Zip) - 364.9Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


17.8.9 清除配置

InnoDB 在使用 SQL 语句删除行时,不会立即物理删除该行。只有当InnoDB 将删除操作的undo日志记录写入磁盘并且该行不再需要用于多版本并发控制(MVCC)或回滚时,才会进行物理删除,这个删除操作称为 purge。

purge 按照固定的时间表运行。它将从历史列表中读取undo日志页,并对其进行处理。历史列表是由InnoDB事务系统维护的,用于存储已提交的事务的undo日志页。purge 在处理完毕后,将释放历史列表中的undo日志页。

purge 操作在背景中由一个或多个 purge 线程执行。purge 线程的数量由innodb_变量控制。默认情况下,如果可用逻辑处理器少于 16 个,则默认值为 1,否则默认值为 4。

如果DML操作集中在单个表上,purge操作将由单个purge线程执行,这可能会导致purge操作速度减慢、purge延迟增加和表空间文件大小增加,如果DML操作涉及到大对象值。 如果超过了innodb_max_purge_lag设置,purge工作将自动重新分配给可用purge线程。 在这种情况下,有太多活动purge线程可能会导致与用户线程的竞争,因此需要相应地管理innodb_purge_threads设置。默认情况下,innodb_max_purge_lag变量被设置为0,这意味着没有默认的最大purge延迟。

如果DML操作集中在少数表上,请将innodb_purge_threads设置保持低,以免线程之间竞争访问忙碌的表。如果DML操作spread across多个表,考虑提高innodb_purge_threads设置。purge线程的最大数量为32。

innodb_purge_threads设置是允许的purge线程的最大数量。purge系统将自动调整使用的purge线程数量。

变量innodb_purge_batch_size定义了purge解析器和处理的undo日志页数批次大小。默认值为300。在多线程purge配置中,协调purge线程将innodb_purge_batch_size除以innodb_purge_threads,并将该页数分配给每个purge线程。

purge系统还会释放不再需要的undo日志页。它每128次遍历undo日志时都会这样做。此外,变量innodb_purge_batch_size还定义了purge每128次遍历undo日志时释放的undo日志页数。

变量innodb_purge_batch_size旨为高级性能调整和实验。大多数用户不需要从默认值更改innodb_purge_batch_size

变量innodb_max_purge_lag定义了期望的最大purge延迟。当purge延迟超过innodb_max_purge_lag阈值时,对INSERTUPDATEDELETE操作将被延迟,以便purge操作有时间来catch up。默认值为0,这意味着没有最大purge延迟且没有延迟。

InnoDB事务系统维护了一个由UPDATEDELETE操作删除标记的索引记录列表。列表长度是purge延迟。

purge延迟计算公式如下:

(purge_lag/innodb_max_purge_lag - 0.9995) * 10000

延迟是在purge批处理开始时计算的。

对于问题工作负载,可能需要设置innodb_max_purge_lag为1000000(1,000,000),假设事务小,只有100字节大小,并且允许未purge的表行占用100MB空间。

清除延迟被表示为 History list length 值在SHOW ENGINE INNODB STATUS 输出的 TRANSACTIONS 部分中。

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)系统必须将数据保留在undo日志中,直到所有依赖该数据的事务都完成。以下是一些可能导致 History list length 增加的长时间运行事务示例:

为了防止极端情况下purge延迟变得非常大,您可以通过设置innodb_max_purge_lag_delay变量来限制延迟。innodb_max_purge_lag_delay变量指定了当innodb_max_purge_lag阈值超过时,延迟的最大时间(微秒)。指定的innodb_max_purge_lag_delay值是对由innodb_max_purge_lag公式计算的延迟期限的上限。

Purge and Undo 表pace Truncation

purge系统还负责截断undo表空间。您可以通过设置innodb_purge_rseg_truncate_frequency变量来控制purge系统查找undo表空间截断的频率。更多信息,请见截断Undo表空间