Purge Configuration The  innodb_spin_wait_delay  and  innodb_spin_wait_pause_multiplier  variables are dynamic. They can be specified in a MySQL option file or modified at runtime using a  SET GLOBAL statement. Modifying the variables at runtime requires privileges sufficient to set global system variables. See Section 5.1.9.1, “System Variable Privileges” . InnoDB  does not physically remove a row from the database immediately when you delete it with an SQL statement. A row and its index records are only physically removed when  InnoDB  discards the undo log record written for the deletion. This removal operation, which only occurs after the row is no longer required for multi-version concurrency control (MVCC) or rollback, is called a purge. Purge runs on a periodic schedule. It parses and processes undo log pages from the history list, which is a list of undo log pages for committed transactions that is maintained by the  InnoDB  transaction system. Purge frees the undo log pages from the history list after processing them. Purge operations are performed in the background by one or more purge threads. The number of purge threads is controlled by the  innodb_purge_threads  variable. The default value is 4. If DML action is concentrated on a single table, purge operations for the table are performed by a single purge thread, which can result in slowed purge operations, increased purge lag, and increased tablespace file size if the DML operations involve large object values. From MySQL 8.0.26, if the innodb_max_purge_lag  setting is exceeded, purge work is automatically redistributed among available purge threads. Too many active purge threads in this scenario can cause contention with user threads, so manage the  innodb_purge_threads  setting accordingly. The  innodb_max_purge_lag  variable is set to 0 by default, which means that there is no maximum purge lag by default. If DML action is concentrated on few tables, keep the  innodb_purge_threads  setting low so that the threads do not contend with each other for access to the busy tables. If DML operations are spread across many tables, consider a higher  innodb_purge_threads  setting. The maximum number of purge threads is 32. The  innodb_purge_threads  setting is the maximum number of purge threads permitted. The purge system automatically adjusts the number of purge threads that are used. The  innodb_purge_batch_size  variable defines the number of undo log pages that purge parses and processes in one batch from the history list. The default value is 300. In a multithreaded purge configuration, the coordinator purge thread divides  innodb_purge_batch_size  by innodb_purge_threads  and assigns that number of pages to each purge thread. The purge system also frees the undo log pages that are no longer required. It does so every 128 iterations through the undo logs. In addition to defining the number of undo log pages parsed and processed in a batch, the  innodb_purge_batch_size  variable defines the number of undo log pages that purge frees every 128 iterations through the undo logs. The  innodb_purge_batch_size  variable is intended for advanced performance tuning and experimentation. Most users need not change  innodb_purge_batch_size  from its default value. The  innodb_max_purge_lag  variable defines the desired maximum purge lag. When the purge lag exceeds the  innodb_max_purge_lag  threshold, a delay is imposed on  INSERT ,  UPDATE , and  DELETE 15.8.9 Purge Configuration Configuring Purge Threads Configuring Purge Batch Size Configuring the Maximum Purge Lag 3129