The Binary Log CREATE TABLE ... SELECT  is a combination of data definition and data manipulation. The  CREATE TABLE  part is logged using statement format and the  SELECT  part is logged according to the value of binlog_format . From MySQL 8.0.20, you can enable binary log transaction compression on a MySQL server instance. When binary log transaction compression is enabled, transaction payloads are compressed using the zstd algorithm, and then written to the server’s binary log file as a single event (a Transaction_payload_event ). Compressed transaction payloads remain in a compressed state while they are sent in the replication stream to replicas, other Group Replication group members, or clients such as  mysqlbinlog . They are not decompressed by receiver threads, and are written to the relay log still in their compressed state. Binary log transaction compression therefore saves storage space both on the originator of the transaction and on the recipient (and for their backups), and saves network bandwidth when the transactions are sent between server instances. Compressed transaction payloads are decompressed when the individual events contained in them need to be inspected. For example, the  Transaction_payload_event  is decompressed by an applier thread in order to apply the events it contains on the recipient. Decompression is also carried out during recovery, by  mysqlbinlog  when replaying transactions, and by the  SHOW BINLOG EVENTS  and  SHOW RELAYLOG EVENTS  statements. You can enable binary log transaction compression on a MySQL server instance using the binlog_transaction_compression  system variable, which defaults to  OFF . You can also use the binlog_transaction_compression_level_zstd  system variable to set the level for the zstd algorithm that is used for compression. This value determines the compression effort, from 1 (the lowest effort) to 22 (the highest effort). As the compression level increases, the compression ratio increases, which reduces the storage space and network bandwidth required for the transaction payload. However, the effort required for data compression also increases, taking time and CPU and memory resources on the originating server. Increases in the compression effort do not have a linear relationship to increases in the compression ratio. The following types of event are excluded from binary log transaction compression, so are always written uncompressed to the binary log: Binary log encryption can be used on binary log files that contain compressed transactions. Transactions with payloads that are compressed can be rolled back like any other transaction, and they can also be filtered out on a replica by the usual filtering options. Binary log transaction compression can be applied to XA transactions. When binary log transaction compression is enabled, the  max_allowed_packet  and slave_max_allowed_packet  limits for the server still apply, and are measured on the compressed size •Events relating to the GTID for the transaction (including anonymous GTID events). •Other types of control event, such as view change events and heartbeat events. •Incident events and the whole of any transactions that contain them. •Non-transactional events and the whole of any transactions that contain them. A transaction involving a mix of non-transactional and transactional storage engines does not have its payload compressed. •Events that are logged using statement-based binary logging. Binary log transaction compression is only applied for the row-based binary logging format. Behaviors When Binary Log Transaction Compression is Enabled 5.4.4.5 Binary Log Transaction Compression 1060