MySQL 9.0 發行說明
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 控制壓縮層級。在命令列或 my.cnf 檔案中使用 --binlog-transaction-compression 啟動 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 會顯示交易處於其交易承載資料的解壓縮或壓縮階段的時間，並顯示此階段的進度。壓縮是由處理交易的工作者執行緒在交易認可之前執行，前提是已完成擷取快取中沒有排除交易二進位日誌交易壓縮的事件（例如事件事件）。如果需要解壓縮，則會一次從承載資料中解壓縮一個事件。
使用 mysqlbinlog 並加上 --verbose 選項，會包含註解說明壓縮交易酬載的壓縮後大小、未壓縮大小，以及使用的壓縮演算法。
您可以使用 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 節「訊息壓縮」。