When binary logging is enabled on the server, this compression method is not used, and instead the mysql.gtid_executed  table is compressed on each binary log rotation. However, when binary logging is disabled on the server, the  thread/sql/compress_gtid_table  thread sleeps until a specified number of transactions have been executed, then wakes up to perform compression of the  mysql.gtid_executed  table. It then sleeps until the same number of transactions have taken place, then wakes up to perform the compression again, repeating this loop indefinitely. The number of transactions that elapse before the table is compressed, and thus the compression rate, is controlled by the value of the  gtid_executed_compression_period  system variable. Setting that value to 0 means that the thread never wakes up, meaning that this explicit compression method is not used. Instead, compression occurs implicitly as required. From MySQL 8.0.17,  InnoDB  transactions are written to the  mysql.gtid_executed  table by a separate process to non- InnoDB  transactions. This process is controlled by a different thread,  innodb/ clone_gtid_thread . This GTID persister thread collects GTIDs in groups, flushes them to the mysql.gtid_executed  table, then compresses the table. If the server has a mix of  InnoDB  transactions and non- InnoDB  transactions, which are written to the  mysql.gtid_executed  table individually, the compression carried out by the  compress_gtid_table  thread interferes with the work of the GTID persister thread and can slow it significantly. For this reason, from that release it is recommended that you set  gtid_executed_compression_period  to 0, so that the  compress_gtid_table  thread is never activated. From MySQL 8.0.23, the  gtid_executed_compression_period  default value is 0, and both  InnoDB and non- InnoDB  transactions are written to the  mysql.gtid_executed  table by the GTID persister thread. For releases before MySQL 8.0.17, the default value of 1000 for gtid_executed_compression_period  can be used, meaning that compression of the table is performed after each 1000 transactions, or you can choose an alternative value. In those releases, if you set a value of 0 and binary logging is disabled, explicit compression is not performed on the mysql.gtid_executed  table, and you should be prepared for a potentially large increase in the amount of disk space that may be required by the table if you do this. When a server instance is started, if  gtid_executed_compression_period  is set to a nonzero value and the  thread/sql/compress_gtid_table  thread is launched, in most server configurations, explicit compression is performed for the  mysql.gtid_executed  table. In releases before MySQL 8.0.17 when binary logging is enabled, compression is triggered by the fact of the binary log being rotated at startup. In releases from MySQL 8.0.20, compression is triggered by the thread launch. In the intervening releases, compression does not take place at startup. The life cycle of a GTID consists of the following steps: 17.1.3.2 GTID Life Cycle 1. A transaction is executed and committed on the source. This client transaction is assigned a GTID composed of the source’s UUID and the smallest nonzero transaction sequence number not yet used on this server. The GTID is written to the source’s binary log (immediately preceding the transaction itself in the log). If a client transaction is not written to the binary log (for example, because the transaction was filtered out, or the transaction was read-only), it is not assigned a GTID. 3455 Replication with Global Transaction Identifiers PROCESSLIST_INFO: NULL PARENT_THREAD_ID: 1 ROLE: NULL INSTRUMENTED: YES HISTORY: YES CONNECTION_TYPE: NULL THREAD_OS_ID: 18677