MySQL 8.4 版本注意事項
MySQL 支援二進制日誌交易壓縮；啟用此功能後，交易酬載會使用 zstd 演算法壓縮，然後作為單一事件 (Transaction_payload_event) 寫入伺服器的二進制日誌檔案。
壓縮的交易酬載在複寫串流中傳送至複本、其他群組複寫群組成員或用戶端 (例如 mysqlbinlog) 時，會保持壓縮狀態。接收執行緒不會解壓縮它們，並且它們仍以壓縮狀態寫入中繼日誌。因此，二進制日誌交易壓縮可節省交易發起者和接收者 (及其備份) 的儲存空間，並在伺服器執行個體之間傳送交易時節省網路頻寬。
當需要檢查其中包含的個別事件時，會解壓縮壓縮的交易酬載。例如，為了將其中包含的事件套用在接收者上，套用執行緒會解壓縮 Transaction_payload_event。在復原期間，mysqlbinlog 重新播放交易時，以及 SHOW BINLOG EVENTS 和 SHOW RELAYLOG EVENTS 陳述式也會進行解壓縮。
您可以使用 binlog_transaction_compression 系統變數，在 MySQL 伺服器執行個體上啟用二進制日誌交易壓縮，其預設值為 OFF。您也可以使用 binlog_transaction_compression_level_zstd 系統變數來設定用於壓縮的 zstd 演算法的層級。此值決定壓縮工作量，從 1 (最低工作量) 到 22 (最高工作量)。隨著壓縮層級的提高，壓縮率會提高，這會減少交易酬載所需的儲存空間和網路頻寬。然而，資料壓縮所需的工作量也會增加，佔用原始伺服器上的時間、CPU 和記憶體資源。壓縮工作量的增加與壓縮率的增加並非線性關係。
設定 binlog_transaction_compression 或 binlog_transaction_compression_level_zstd (或兩者) 不會立即生效，而是會套用至所有後續的 START REPLICA 陳述式。
注意
您可以使用 ndb_log_transaction_compression 系統變數，在執行時啟用使用 NDB 儲存引擎之資料表的壓縮交易二進制日誌記錄功能，並使用 ndb_log_transaction_compression_level_zstd 控制壓縮等級。使用命令列選項 --binlog-transaction-compression 或在 my.cnf 檔案中啟動 mysqld，會自動啟用 ndb_log_transaction_compression，並忽略 --ndb-log-transaction-compression 選項的任何設定；若要僅針對 NDB 儲存引擎停用二進制日誌交易壓縮，請在啟動 mysqld 之後的用戶端會話中，設定 ndb_log_transaction_compression=OFF。
下列類型的事件會從二進制日誌交易壓縮中排除，因此始終以未壓縮的方式寫入二進制日誌
與交易的 GTID 相關的事件（包括匿名 GTID 事件）。
其他類型的控制事件，例如檢視變更事件和心跳事件。
事件事件和包含它們的任何完整交易。
非交易事件和包含它們的任何完整交易。涉及非交易和交易儲存引擎混合的交易，其有效負載不會被壓縮。
使用基於語句的二進制日誌記錄的事件。二進制日誌交易壓縮僅適用於基於列的二進制日誌格式。
二進制日誌加密可用於包含壓縮交易的二進制日誌檔案。
具有壓縮有效負載的交易可以像任何其他交易一樣回滾，並且它們也可以透過常用的篩選選項在複本上篩選掉。二進制日誌交易壓縮可以應用於 XA 交易。
啟用二進制日誌交易壓縮時，伺服器的 max_allowed_packet 和 replica_max_allowed_packet 限制仍然適用，並且以 Transaction_payload_event 的壓縮大小加上事件標頭所使用的位元組來衡量。
重要
壓縮的交易有效負載是以單一封包傳送，而不是像未使用二進制日誌交易壓縮時一樣，交易的每個事件都以個別封包傳送。如果您的複寫拓撲處理大型交易，請注意，當未使用二進制日誌交易壓縮時可以成功複寫的大型交易，在使用二進制日誌交易壓縮時，可能會因其大小而停止複寫。
對於多執行緒工作執行緒，每個交易（包括其 GTID 事件和 Transaction_payload_event）都會指派給一個工作執行緒。工作執行緒會解壓縮交易有效負載，並逐一應用其中的個別事件。如果在 Transaction_payload_event 中應用任何事件時發現錯誤，則會將整個交易回報給協調器，指出已失敗。當 replica_parallel_type 或 replica_parallel_type 設定為 DATABASE 時，會先對交易影響的所有資料庫進行對應，然後再排定交易。與未壓縮的交易相比，將二進制日誌交易壓縮與 DATABASE 原則搭配使用，可能會降低平行度，未壓縮的交易會針對每個事件進行對應和排程。
對於半同步複寫（請參閱第 19.4.10 節「半同步複寫」），複本會在收到完整的 Transaction_payload_event 時確認交易。
啟用二進制日誌總和檢查碼（這是預設值）時，複寫來源伺服器不會為壓縮交易有效負載中的個別事件寫入總和檢查碼。相反地，會為完整的 Transaction_payload_event 寫入總和檢查碼，並為任何未壓縮的事件（例如與 GTID 相關的事件）寫入個別總和檢查碼。
對於 SHOW BINLOG EVENTS 和 SHOW RELAYLOG EVENTS 陳述式，Transaction_payload_event 會先以單一單位列印，然後會將其解壓縮，並列印其中的每個事件。
對於參照事件結束位置的操作，例如使用 UNTIL 子句的 START REPLICA、SOURCE_POS_WAIT() 和 sql_replica_skip_counter，您必須指定壓縮交易有效負載的結束位置 (Transaction_payload_event)。使用 sql_replica_skip_counter 跳過事件時，壓縮的交易有效負載會被視為單一計數器值，因此其中的所有事件都會以一個單位跳過。
支援二進制日誌交易壓縮的 MySQL Server 版本可以處理壓縮和未壓縮交易有效負載的混合。
與二進制日誌交易壓縮相關的系統變數不需要在所有群組複寫群組成員上設定相同的值，並且不會從來源複寫到複寫拓撲中的複本。您可以決定二進制日誌交易壓縮是否適用於每個具有二進制日誌的 MySQL Server 執行個體。
如果在伺服器上啟用交易壓縮，然後停用，壓縮將不會應用於該伺服器上產生的未來交易，但是仍然可以處理和顯示已壓縮的交易有效負載。
如果透過設定
binlog_transaction_compression的會話值，為個別會話指定交易壓縮，則二進制日誌可以包含壓縮和未壓縮交易有效負載的混合。
當複寫拓撲中的來源及其複本都啟用二進制日誌交易壓縮時，複本會收到壓縮的交易有效負載，並將其壓縮寫入其中繼日誌。它會解壓縮交易有效負載以套用交易，然後在套用後再次壓縮，以便寫入其二進制日誌。任何下游複本都會收到壓縮的交易有效負載。
當複寫拓撲中的來源啟用二進制日誌交易壓縮，但其複本未啟用時，複本會收到壓縮的交易有效負載，並將其壓縮寫入其轉送日誌。它會解壓縮交易有效負載以套用交易，然後將其未壓縮地寫入其自己的二進制日誌（如果有的話）。任何下游複本都會收到未壓縮的交易有效負載。
當複寫拓撲中的來源未啟用二進制日誌交易壓縮，但其複本啟用時，如果複本具有二進制日誌，則它會在套用交易有效負載後將其壓縮，並將壓縮的交易有效負載寫入其二進制日誌。任何下游複本都會收到壓縮的交易有效負載。
當 MySQL 伺服器執行個體沒有二進制日誌時，無論其 binlog_transaction_compression 的值為何，都可以接收、處理和顯示壓縮的交易有效負載。此類伺服器執行個體接收的壓縮交易有效負載會以壓縮狀態寫入轉送日誌，因此它們間接地從複寫拓撲中其他伺服器執行的壓縮中受益。
您可以使用效能結構描述資料表 binary_log_transaction_compression_stats 來監控二進制日誌交易壓縮的效果。統計資料包括受監控期間的資料壓縮比，您也可以檢視壓縮對伺服器上最後一個交易的影響。您可以截斷資料表來重設統計資料。二進制日誌和中繼日誌的統計資料會分開列出，以便您可以查看每種日誌類型的壓縮影響。MySQL 伺服器執行個體必須具有二進制日誌才能產生這些統計資料。
效能結構描述資料表 events_stages_current 顯示交易處於其交易有效負載的解壓縮或壓縮階段的時間，並顯示此階段的進度。壓縮由處理交易的工作執行緒在交易提交之前執行，前提是在最終擷取快取中沒有任何將交易排除在二進制日誌交易壓縮之外的事件（例如事件事件）。當需要解壓縮時，每次會從有效負載中執行一個事件。
具有 --verbose 選項的 mysqlbinlog 包含註解，指出壓縮的交易有效負載的壓縮大小和未壓縮大小，以及所使用的壓縮演算法。
您可以使用 CHANGE REPLICATION SOURCE TO 陳述式的 SOURCE_COMPRESSION_ALGORITHMS 和 SOURCE_ZSTD_COMPRESSION_LEVEL 選項，或使用 replica_compressed_protocol 系統變數，在複寫連線的協定層級啟用連線壓縮。如果您在也啟用連線壓縮的系統中啟用二進制日誌交易壓縮，連線壓縮的影響會降低，因為可能沒有太多機會進一步壓縮壓縮的交易有效負載。但是，連線壓縮仍然可以在未壓縮的事件和訊息標頭上運作。如果需要節省儲存空間和網路頻寬，可以結合使用二進制日誌交易壓縮和連線壓縮。如需複寫連線的連線壓縮詳細資訊，請參閱第 6.2.8 節「連線壓縮控制」。
對於群組複製，預設會啟用訊息壓縮，壓縮的訊息需超過由 group_replication_compression_threshold 系統變數設定的閾值。您也可以使用 group_replication_recovery_compression_algorithms 和 group_replication_recovery_zstd_compression_level 系統變數，針對從捐贈者的二進位日誌進行狀態傳輸的分布式恢復所傳送的訊息設定壓縮。如果您在已設定這些變數的系統中啟用二進位日誌交易壓縮，群組複製的訊息壓縮仍然可以對未壓縮的事件和訊息標頭進行操作，但其影響會降低。有關群組複製訊息壓縮的更多資訊，請參閱第 20.7.4 節「訊息壓縮」。