MySQL 8.0版本说明
MySQL 8.0源代码文档10bet官方网站
从MySQL 8.0.20开始，您可以在MySQL服务器实例上启用二进制日志事务压缩。当启用二进制日志事务压缩时，将使用zstd算法压缩事务有效负载，然后将事务有效负载作为单个事件(aTransaction_payload_event)．当压缩事务有效负载在复制流中发送到副本、其他Group replication组成员或客户端时，它们保持压缩状态mysqlbinlog．它们不会被接收线程解压缩，而是被写入中继日志，仍然处于压缩状态。因此，二进制日志事务压缩在事务发起者和接收者(以及他们的备份)上都节省了存储空间，并且在服务器实例之间发送事务时节省了网络带宽。
当需要检查包含在压缩事务有效负载中的单个事件时，将解压压缩事务有效负载。例如,Transaction_payload_event由应用程序线程解压缩，以便将其包含的事件应用于收件人。在恢复过程中也进行减压mysqlbinlog当重放事务时，并通过显示BINLOG的事件而且显示RELAYLOG的事件语句。
可以在MySQL服务器实例上启用二进制日志事务压缩binlog_transaction_compression系统变量，默认为从．你也可以使用binlog_transaction_compression_level_zstd为用于压缩的ZSTD算法设置级别的系统变量。这个值决定了压缩工作量，从1(最低工作量)到22(最高工作量)。随着压缩级别的增加，压缩比也会增加，这将减少事务有效负载所需的存储空间和网络带宽。但是，数据压缩所需的工作量也会增加，会占用原始服务器上的时间、CPU和内存资源。压缩努力的增加与压缩比的增加没有线性关系。
以下类型的事件从二进制日志事务压缩中排除，因此总是未压缩地写入二进制日志:
与事务的GTID相关的事件(包括匿名GTID事件)。
其他类型的控制事件，例如视图更改事件和心跳事件。
事件事件和包含它们的所有事务。
非事务性事件和包含它们的所有事务。混合了非事务性和事务性存储引擎的事务没有对其有效负载进行压缩。
使用基于语句的二进制日志记录的事件。二进制日志事务压缩只应用于基于行的二进制日志格式。
二进制日志加密可用于包含压缩事务的二进制日志文件。
具有压缩有效负载的事务可以像任何其他事务一样回滚，它们也可以通过通常的过滤选项在副本上过滤掉。二进制日志事务压缩可以应用于XA事务。
当启用二进制日志事务压缩时，max_allowed_packet而且slave_max_allowed_packet服务器的限制仍然适用，并根据压缩后的大小进行测量Transaction_payload_event，加上用于事件头的字节。注意，压缩的事务有效负载作为单个包发送，而不是像二进制日志事务压缩不使用时那样，在单个包中发送事务的每个事件。
对于多线程工作者，每个事务(包括它的GTID事件和Transaction_payload_event)被分配给一个工作线程。工作线程解压缩事务有效负载，并逐个应用其中的单个事件。对象中应用任何事件时发现错误Transaction_payload_event时，整个事务将被报告给协调器，称其失败。当slave_parallel_type被设置为数据库，在调度事务之前映射受事务影响的所有数据库。使用二进制日志事务压缩数据库与未压缩事务相比，策略可以减少并行性，未压缩事务为每个事件映射和调度。
有关半同步复制(请参阅17.4.10节“半同步复制”)，副本在完成时确认事务Transaction_payload_event已经收到。
当启用二进制日志校验和(这是默认值)时，复制源服务器不会为压缩事务有效负载中的单个事件写入校验和。相反，校验和是为完成式编写的Transaction_payload_event，并且为任何未压缩的事件写入单独的校验和，例如与gtid相关的事件。
为显示BINLOG的事件而且显示RELAYLOG的事件语句,Transaction_payload_event首先作为单个单元打印，然后拆开包装并打印其中的每个事件。
对于引用事件结束位置的操作，例如启动|副本slave与直到条款,MASTER_POS_WAIT (),sql_slave_skip_counter，您必须指定压缩事务有效负载的结束位置Transaction_payload_event)．当使用sql_slave_skip_counter，压缩的事务有效负载被计算为单个计数器值，因此其中的所有事件作为一个单元被跳过。
支持二进制日志事务压缩的MySQL Server版本可以处理压缩和未压缩事务负载的混合。
与二进制日志事务压缩相关的系统变量不需要在所有Group Replication组成员上设置相同，也不需要在复制拓扑中从源复制到副本。您可以决定二进制日志事务压缩是否适用于每个具有二进制日志的MySQL Server实例。
如果在服务器上启用了事务压缩，然后禁用了事务压缩，则不会将压缩应用于该服务器上产生的未来事务，但是仍然可以处理和显示已压缩的事务有效负载。
的会话值为单个会话指定事务压缩
binlog_transaction_compression，二进制日志可以混合包含压缩和未压缩事务有效负载。
当复制拓扑中的源及其副本都启用了二进制日志事务压缩时，副本接收压缩的事务有效负载，并将压缩后的事务有效负载写入其中继日志。它解压事务有效负载以应用事务，然后在申请写入其二进制日志后再次压缩事务。任何下游副本都接收压缩的事务有效负载。
当复制拓扑中的源启用了二进制日志事务压缩，但其副本没有启用时，副本接收压缩的事务有效负载，并将压缩后的事务有效负载写入其中继日志。它解压事务有效负载以应用事务，然后将未压缩的事务写入自己的二进制日志(如果有的话)。任何下游副本都接收未压缩的事务有效负载。
当复制拓扑中的源没有启用二进制日志事务压缩，但其副本启用了二进制日志事务压缩时，如果副本具有二进制日志，则在应用事务有效负载后压缩事务有效负载，并将压缩的事务有效负载写入其二进制日志。任何下游副本都接收压缩的事务有效负载。
当MySQL服务器实例没有二进制日志时，如果它是MySQL 8.0.20的版本，它可以接收、处理和显示压缩事务有效负载，而不管它的值是多少binlog_transaction_compression．此类服务器实例接收到的压缩事务有效负载将以压缩状态写入中继日志，因此它们间接受益于复制拓扑中其他服务器执行的压缩。
在MySQL 8.0.20之前的版本中，如果启用了二进制日志事务压缩，则无法从源进行复制。MySQL 8.0.20或更高版本的副本可以从不支持二进制日志事务压缩的较早版本中的源进行复制，并可以在将从该源接收的事务写入自己的二进制日志时对其执行自己的压缩。
可以使用Performance Schema表监视二进制日志事务压缩的效果binary_log_transaction_compression_stats．统计信息包括监控周期内的数据压缩比，还可以查看压缩对服务器上最后一个事务的影响。可以通过截断表来重置统计信息。二进制日志和中继日志的统计信息被分离出来，因此您可以看到每种日志类型的压缩影响。MySQL服务器实例必须有一个二进制日志来产生这些统计信息。
性能架构表events_stages_current显示事务何时处于事务有效负载的解压缩或压缩阶段，并显示此阶段的进度。压缩是由处理事务的工作线程在事务提交之前执行的，前提是最终捕获缓存中没有将事务排除在二进制日志事务压缩之外的事件(例如，事件事件)。当需要解压缩时，它一次针对有效负载中的一个事件执行。
mysqlbinlog与——详细选项包括说明压缩事务有效负载的压缩大小和未压缩大小的注释，以及使用的压缩算法。
方法可以在协议级别为复制连接启用连接压缩SOURCE_COMPRESSION_ALGORITHMS|MASTER_COMPRESSION_ALGORITHMS而且SOURCE_ZSTD_COMPRESSION_LEVEL|MASTER_ZSTD_COMPRESSION_LEVEL选项的将复制源更改为语句(从MySQL 8.0.23)或改变主语句(MySQL 8.0.23之前的版本)，或已弃用的slave_compressed_protocol系统变量。如果您在一个同时启用了连接压缩的系统中启用了二进制日志事务压缩，则连接压缩的影响将会减少，因为可能几乎没有机会进一步压缩压缩的事务有效负载。但是，连接压缩仍然可以操作未压缩的事件和消息头。如果需要节省存储空间和网络带宽，可以将二进制日志事务压缩与连接压缩结合使用。有关复制连接的连接压缩的详细信息，请参见第4.2.8节，“连接压缩控制”．
属性设置的阈值以外的消息默认启用压缩group_replication_compression_threshold系统变量。方法还可以配置为分布式恢复而发送的消息的压缩，方法是从捐赠者的二进制日志的状态传输group_replication_recovery_compression_algorithms而且group_replication_recovery_zstd_compression_level系统变量。如果在配置了二进制日志事务压缩的系统中启用了二进制日志事务压缩，则Group Replication的消息压缩仍然可以操作未压缩的事件和消息头，但其影响会降低。有关用于组复制的消息压缩的详细信息，请参见第18.7.3节，“消息压缩”．