文档首页
MySQL 9.0 参考手册
相关文档 下载本手册
PDF (US Ltr) - 40.0Mb
PDF (A4) - 40.1Mb
手册页 (TGZ) - 258.2Kb
手册页 (Zip) - 365.3Kb
信息 (Gzip) - 4.0Mb
信息 (Zip) - 4.0Mb


MySQL 9.0 参考手册  /  ...  /  清理配置

17.8.9 清理配置

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

清理操作按定期计划运行。它会解析和处理历史列表中的撤消日志页面,该列表是由 InnoDB 事务系统维护的已提交事务的撤消日志页面列表。清理操作在处理完撤消日志页面后,会将它们从历史列表中释放出来。

配置清理线程

清理操作由一个或多个清理线程在后台执行。清理线程的数量由 innodb_purge_threads 变量控制。如果可用逻辑处理器数量小于等于 16,则默认值为 1,否则默认值为 4。

如果 DML 操作集中在一个表上,则该表的清理操作由单个清理线程执行,这可能会导致清理操作变慢、清理滞后增加,以及如果 DML 操作涉及大型对象值,则表空间文件大小会增加。如果超过了 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 阈值时,INSERTUPDATEDELETE 操作将被延迟,以便为清除操作争取时间。 默认值为 0,这意味着没有最大清除滞后时间,也没有延迟。

InnoDB 事务系统维护着一个事务列表,这些事务的索引记录已通过 UPDATEDELETE 操作标记为删除。 列表的长度即为清除滞后时间。

清除滞后延迟由以下公式计算得出:

(purge_lag/innodb_max_purge_lag - 0.9995) * 10000

延迟在清除批处理开始时计算。

对于存在问题的负载,典型的 innodb_max_purge_lag 设置可能是 1000000(100 万),假设事务很小,只有 100 字节,并且允许有 100MB 的未清除表行。

清除滞后时间在 SHOW ENGINE INNODB STATUS 输出的 TRANSACTIONS 部分中显示为 History list length 值。

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 公式计算出的延迟周期的上限。

清除和撤消表空间截断

清除系统还负责截断撤消表空间。您可以配置 innodb_purge_rseg_truncate_frequency 变量来控制清除系统查找要截断的撤消表空间的频率。 有关更多信息,请参阅 截断撤消表空间