MySQL中purge线程知识：

https://dev.mysql.com/doc/refman/5.7/en/innodb-improved-purge-scheduling.html


InnoDB中delete所做删除只是标记为删除的状态，实际上并没有删除掉，因为MVCC机制的存在，要保留之前的版本为并发所使用。最终的删除由purge线程来决定的什么时候来真正删除文件的。


purge的处理过程： InnoDB存储引擎第二版 Page 317 - 318


innodb_purge_batch_size参数：

用来设置每次purge操作需要清理的undo log page的数量。【默认300，表示每次清理300个page，支持动态修改】

设置的越大，表示每次回收的页也就越多，可供重用的undo page也就越多，就能减少磁盘存储空间与分配的开销。不过该参数设置得太大，则每次需要purge处理更多的undo page，从而导致CPU和磁盘IO过于集中于对undo log的处理，使性能下降。普通用户不建议调整这个参数。


> show VARIABLES like 'innodb_purge_batch%';

+-------------------------+---------+

| Variable_name           |   Value |

|-------------------------+---------|

| innodb_purge_batch_size |     300 |

+-------------------------+---------+



innodb_purge_threads 参数：

当有很多的表进行DML操作时候， 增大 innodb_purge_threads 能提高purge的效率(清理掉MVCC机制导致的老旧数据)。

现在的MySQL版本中。purge线程已经从master线程中独立出来,使用单独的线程提高了可伸缩性。

从MySQL5.7.8开始，这个参数默认是4，最大可以设置为32.【老版本里面这个值默认是1】



innodb_max_purge_lag 参数：

当InnoDB存储引擎的压力非常大时，并不能高效地进行purge操作。那么history list(undo log page数量)的长度会变得越来越长。innodb_max_purge_lag 就是控制history list的长度，若长度大于该值，就会延缓DML的操作。该值默认为0，表示不做任何限制。【不建议修改这个参数值!! 】


innodb_max_purge_lag_delay 参数：

表示当上面innodb_max_purge_lag的delay超时时间太大，超过这个参数时，将delay设置为该参数值，防止purge线程操作缓慢导致其他SQL线程长期处于等待状态。默认为0，一般不用修改。




一个关于删除数据后磁盘空间再次利用的实验：

会话1：

use test;

CREATE TABLE `t1` (`a` int(11) NOT NULL AUTO_INCREMENT, `b` int(11) DEFAULT '100', `c` varchar(10) NOT NULL DEFAULT 'cccc', PRIMARY KEY (`a`)) ;

insert into t1 (b,c) select 111,'cccccc';


会话2：

cd /data/mysql/test/

watch -n 1 'ls -lh t1.ibd'


然后再到会话1去多次执行插入数据的操作 insert into t1 (b,c) select b,c from t1 ;  重复执行多次，可以看到会话2的t1.ibd在不断在的增大。


假设等到t1.ibd增大到112MB时候，我们到会话1去一个全量的删除操作delete from t1 where 1=1; 然后少等片刻(等purge线程自动清理数据、master线程将数据落盘)。


这时候去观察到会话2窗口，可以看到的t1.ibd文件体积一点也没有减少。


再次到t会话1窗口去执行少量的插入操作，并观察会话2的t1.ibd文件体积。


可以看到t1.ibd文件的体积没有再次增长，(原因：purge线程将上述实验中被删除数据部分对应的磁盘空间标记为可用，可以被后续写入操作使用，这样就不用再次分配磁盘空间了)。