Connection Compression with X Plugin If the server and client permit more than one algorithm in common, the default priority order for choosing an algorithm during negotiation is shown in Table 20.1, “X Protocol Compression Algorithm Characteristics” . From MySQL 8.0.22, for clients that support specifying compression algorithms, the connection request can include a list of algorithms permitted by the client, specified using the algorithm name or its alias. The order of these algorithms in the list is taken as a priority order by the server. The algorithm used in this case is the first of those in the client list that is also permitted on the server side. However, the option for compression algorithms is subject to the compression mode: To monitor the effects of message compression, use the X Plugin status variables described in Monitoring Connection Compression for X Plugin. You can use these status variables to calculate the benefit of message compression with your current settings, and use that information to tune your settings. 3890 Compressed Connection Characteristics for X Plugin •If the compression mode is  disabled , the compression algorithms option is ignored. •If the compression mode is  preferred  but no algorithm permitted on the client side is permitted on the server side, the connection is uncompressed. •If the compression mode is  required  but no algorithm permitted on the client side is permitted on the server side, an error occurs. X Protocol connection compression operates with the following behaviors and boundaries: •The  _stream  and  _message  suffixes in algorithm names refer to two different operational modes: In stream mode, all X Protocol messages in a single connection are compressed into a continuous stream and must be decompressed in the same manner—following the order they were compressed and without skipping any messages. In message mode, each message is compressed individually and independently, and need not be decompressed in the order in which they were compressed. Also, message mode does not require all compressed messages to be decompressed. •Compression is not applied to any messages that are sent before authentication succeeds. •Compression is not applied to control flow messages such as  Mysqlx.Ok ,  Mysqlx.Error , and Mysqlx.Sql.StmtExecuteOk  messages. •All other X Protocol messages can be compressed if the server and client agree on a mutually permitted compression algorithm during capability negotiation. If the client does not request compression at that stage, neither the client nor the server applies compression to messages. •When messages sent over X Protocol connections are compressed, the limit specified by the mysqlx_max_allowed_packet  system variable still applies. The network packet must be smaller than this limit after the message payload has been decompressed. If the limit is exceeded, X Plugin returns a decompression error and closes the connection. •The following points pertain to compression level requests by clients, which is supported only by MySQL Shell: •Compression levels must be specified by the client as an integer. If any other type of value is supplied, the connection closes with an error. •If a client specifies an algorithm but not a compression level, the server uses its default compression level for the algorithm. •If a client requests an algorithm compression level that exceeds the server maximum permitted level, the server uses the maximum permitted level.