diff --git a/mysql/mysql文档/mysql_事务.md b/mysql/mysql文档/mysql_事务.md
index c3ef1b4..4521e72 100644
--- a/mysql/mysql文档/mysql_事务.md
+++ b/mysql/mysql文档/mysql_事务.md
@@ -550,3 +550,23 @@ innodb存储引擎中维护了一个history列表，其`根据事务的提交顺
 - 找到trx2 undo log所在的undo页，然后清理trx 6和trx 4
 
 上述流程中，purge会首先从history list中查找undo log，然后会随便清除undo log位于的undo page中其他可以被清理的undo log，`这样能够减少page的随机访问次数，提高性能`。
+
+##### innodb_purge_batch_size
+`innodb_purge_batch_size`用于设置每次purge操作需要清理的undo page数量，该值默认为`300`。
+
+通常，该值设置越大，每次回收的undo page越多，可供重用的undo page也越多，会减少新开undo page的开销。但是，该值设置过大时，会增加purge占用的cpu和io资源，令用户线程的资源减少。
+
+##### innodb_max_purge_lag
+当innodb存储引擎压力较大时，并无法高效进行purge操作。此时，history list长度会越来越长。
+
+参数`innodb_max_purge_lag`用于控制history list的长度，当history list长度大于`innodb_max_purge_lag`的值时（`innodb_max_purge_lag`值需大于0），会对用户的DML操作进行延缓，延缓算法如下：
+```
+delay = ((length(history_list) - innodb_max_purge_lag) * 10) - 5
+```
+其中，delay的值为ms，且delay针对的是每一行。例如，当一个update操作需要更新5行数据时，每行数据都要被delay，故而故而该update操作的总delay为`5 * delay`。
+
+delay会在每一次purge操作完成后重新计算。
+
+##### innodb_max_purge_lag_delay
+该参数用于控制delay的最大值。当基于公式计算出的delay大于`innodb_max_purge_lag_delay`时，delay的值取`innodb_max_purge_lag_delay`，避免delay值过大导致用户线程无限等待。
+