Skip to content

innodb_max_purge_lag

Jump to bottom
xiaoboluo768 edited this page Jun 14, 2020 · 2 revisions
  • 控制当purge操作滞后时如何延迟INSERT，UPDATE和DELETE操作。默认值为0，表示不延迟DML操作。
    • InnoDB事务系统维护着一个由UPDATE或DELETE操作删除标记的索引记录的事务列表。列表的长度表示purge延迟的值（正常情况下无工作负载操作时，历史列表长度维系着一个小数字的值，那么历史列表的值并不会延迟DML操作，如果你在这个时候把innodb_max_purge_lag设置为一个小于 通过show engine innodb status\G;查看到的History list length N中的N值，DML并不会被延迟）。当purge延迟数量超出innodb_max_purge_lag系统参数的值时，INSERT，UPDATE和DELETE操作将被延迟
    • 为了防止在purge延迟变的极端大的情况下导致DML出现过大的延迟，您可以通过设置innodb_max_purge_lag_delay系统参数来限制在这种情况下的DML最大延迟时间。延迟时间的计算是从最近一次批量清除开始时计算的
    • 例如：有问题的工作负载示例：假设历史列表长度为100万，且事务很小，每个事务的数据大小只有100个字节，那么就表示允许有100MB的未刷新的旧的InnoDB表数据行存在与undo log中
    • 在InnoDB Monitor输出的TRANSACTIONS部分中，滞后值显示为历史列表长度。例如，如果输出包含History list length 20 ，表示滞后值为20
    • 全局变量，动态变量，整型值，默认值为0，取值范围为：0~4294967295，单位为历史列表长度中的事务个数

上一篇：innodb_purge_batch_size | 下一篇：innodb_default_row_format

  • 本 WIKI 包含了《千金良方--MySQL 性能优化金字塔法则》一书的代码段加粗命令行命令和SQL语句文本、以及4个附录内容，其中：

  • 《千金良方--MySQL 性能优化金字塔法则》 一书的作者信息如下：

    • 李春、罗小波、董红禹

  • 联系人QQ：309969177

  • 提示：

    • 附录内容主要的验证、测试、整理工作由本人罗小波完成。鉴于本人精力和能力有限，难免出现一些纰漏，欢迎大家踊跃指正！
    • 如有购书需求，请自行前往京东、当当等平台购买，快捷入口如下：
    • 注：本书主要基于MySQL 5.7撰写，同时，涉及到了少量的MySQL 5.6和MySQL 8.0内容作为参照对比

  • 郑重声明：本WIKI仓库中的资料为电子工业出版社与本书的三位作者共同授权开源，为了在方便大家的同时，避免不必要的纠葛，任何商业与非商业的引用、转载，麻烦大家注明出处，谢谢配合！

Clone this wiki locally