--binlog-row-event-max-size=N

當使用基於列的二進制日誌記錄時，此設定是對基於列的二進制日誌事件最大大小（以位元組為單位）的軟性限制。在可能的情況下，二進制日誌中儲存的列會分組到大小不超過此設定值的事件中。如果無法分割事件，則可能會超過最大大小。該值必須是 256 的倍數（否則會向下捨入為 256 的倍數）。預設值為 8192 位元組。

--log-bin[=base_name]

指定用於二進制日誌檔案的基本名稱。啟用二進制日誌記錄後，伺服器會將所有變更資料的陳述式記錄到二進制日誌中，該日誌用於備份和複製。二進制日誌是一系列具有基本名稱和數字擴展名的檔案。 --log-bin 選項的值是日誌序列的基本名稱。伺服器會通過在基本名稱後添加數字後綴來依序建立二進制日誌檔案。

如果您不提供 --log-bin 選項，MySQL 會使用 binlog 作為二進制日誌檔案的預設基本名稱。為了與早期版本相容，如果您提供的 --log-bin 選項沒有字串或為空字串，則基本名稱預設為 host_name-bin，使用主機的名稱。

二進制日誌檔案的預設位置是資料目錄。您可以使用 --log-bin 選項指定其他位置，方法是在基本名稱前添加前導絕對路徑名稱以指定不同的目錄。當伺服器從二進制日誌索引檔案（追蹤已使用的二進制日誌檔案）讀取條目時，它會檢查該條目是否包含相對路徑。如果包含，則路徑的相對部分會被使用 --log-bin 選項設定的絕對路徑取代。記錄在二進制日誌索引檔案中的絕對路徑保持不變；在這種情況下，必須手動編輯索引檔案才能啟用新的路徑或路徑。二進制日誌檔案基本名稱和任何指定的路徑都可用作 log_bin_basename 系統變數。

在 MySQL 8.4 中，無論您是否指定 --log-bin 選項，預設情況下都會啟用二進制日誌記錄。例外情況是，如果您使用 mysqld 並使用 --initialize 或 --initialize-insecure 選項手動初始化資料目錄，此時預設情況下會停用二進制日誌記錄。在這種情況下，可以通過指定 --log-bin 選項來啟用二進制日誌記錄。啟用二進制日誌記錄後，顯示伺服器上二進制日誌記錄狀態的 log_bin 系統變數會設定為 ON。

要停用二進制日誌記錄，您可以在啟動時指定 --skip-log-bin 或 --disable-log-bin 選項。如果指定了其中任何一個選項，並且也指定了 --log-bin，則稍後指定的選項優先。停用二進制日誌記錄後，log_bin 系統變數會設定為 OFF。

當伺服器上正在使用 GTID 時，如果您在異常關閉後重新啟動伺服器時停用二進制日誌記錄，則可能會遺失一些 GTID，導致複製失敗。在正常關閉時，目前二進制日誌檔案中的 GTID 集會儲存在 mysql.gtid_executed 資料表中。在發生未執行此操作的異常關閉後，在復原期間，GTID 會從二進制日誌檔案新增到資料表中，前提是仍啟用二進制日誌記錄。如果伺服器重新啟動時停用了二進制日誌記錄，則伺服器無法存取二進制日誌檔案來復原 GTID，因此無法啟動複製。在正常關閉後可以安全地停用二進制日誌記錄。

--log-replica-updates 和 --replica-preserve-commit-order 選項需要二進制日誌記錄。如果您停用二進制日誌記錄，請省略這些選項，或指定 --log-replica-updates=OFF 和 --skip-replica-preserve-commit-order。當指定 --skip-log-bin 或 --disable-log-bin 時，MySQL 預設會停用這些選項。如果您將 --log-replica-updates 或 --replica-preserve-commit-order 與 --skip-log-bin 或 --disable-log-bin 一起指定，則會發出警告或錯誤訊息。

當啟用二進制日誌記錄時，可以使用預設伺服器 ID 啟動伺服器，但如果您未透過設定 server_id 系統變數來明確指定伺服器 ID，則會發出資訊訊息。對於在複製拓撲中使用的伺服器，您必須為每個伺服器指定唯一的非零伺服器 ID。

有關二進制日誌的格式和管理資訊，請參閱第 7.4.4 節，「二進制日誌」。

--log-bin-index[=file_name]

二進制日誌索引檔案的名稱，其中包含二進制日誌檔案的名稱。預設情況下，它具有與使用 --log-bin 選項為二進制日誌檔案指定的值相同的位置和基本名稱，加上擴展名 .index。如果您未指定 --log-bin，則預設的二進制日誌索引檔案名稱為 binlog.index。如果您指定的 --log-bin 選項沒有字串或為空字串，則預設的二進制日誌索引檔案名稱為 host_name-bin.index，使用主機的名稱。

有關二進制日誌的格式和管理資訊，請參閱第 7.4.4 節，「二進制日誌」。

--binlog-do-db=db_name

此選項會以類似於 --replicate-do-db 影響複寫的方式影響二進制日誌記錄。

此選項的效果取決於使用的是以陳述式為基礎的日誌記錄格式還是以資料列為基礎的日誌記錄格式，如同 --replicate-do-db 的效果取決於使用的是以陳述式為基礎的複寫還是以資料列為基礎的複寫。您應該記住，用於記錄給定陳述式的格式不一定與 binlog_format 的值所指示的格式相同。例如，CREATE TABLE 和 ALTER TABLE 等 DDL 陳述式始終以陳述式形式記錄，而不考慮生效的日誌記錄格式，因此以下以陳述式為基礎的 --binlog-do-db 規則始終適用於確定是否記錄陳述式。

以陳述式為基礎的日誌記錄。僅當預設資料庫（即由 USE 選取的資料庫）為 db_name 時，才會將這些陳述式寫入二進制日誌。若要指定多個資料庫，請多次使用此選項，每個資料庫使用一次；但是，這樣做不會導致記錄跨資料庫陳述式，例如 UPDATE some_db.some_table SET foo='bar'，同時選取不同的資料庫（或沒有資料庫）。

以下範例說明當使用以陳述式為基礎的日誌記錄時，可能不會如預期運作的情況：如果伺服器啟動時使用 --binlog-do-db=sales，並且您發出以下陳述式，則UPDATE 陳述式不會被記錄

USE prices;
UPDATE sales.january SET amount=amount+1000;

這種「僅檢查預設資料庫」行為的主要原因是，很難僅從陳述式本身判斷是否應該複製該陳述式（例如，如果您使用多個資料表 DELETE 陳述式或跨多個資料庫的多個資料表 UPDATE 陳述式）。如果沒有必要，僅檢查預設資料庫而不是所有資料庫也比較快。

當複製給定資料庫時，即使在設定選項時未指定該資料庫，也可能會發生另一個不明顯的情況。如果伺服器啟動時使用 --binlog-do-db=sales，即使在設定 --binlog-do-db 時未包含 prices，也會記錄以下 UPDATE 陳述式

USE sales;
UPDATE prices.discounts SET percentage = percentage + 10;

由於發出 UPDATE 陳述式時 sales 是預設資料庫，因此會記錄 UPDATE。

以資料列為基礎的日誌記錄。日誌記錄僅限於資料庫 db_name。僅記錄對屬於 db_name 的資料表所做的變更；預設資料庫對此沒有影響。假設伺服器啟動時使用 --binlog-do-db=sales 並且以資料列為基礎的日誌記錄生效，然後執行以下陳述式

USE prices;
UPDATE sales.february SET amount=amount+100;

會根據 UPDATE 陳述式記錄 sales 資料庫中 february 資料表的變更；無論是否發出 USE 陳述式，都會發生這種情況。但是，當使用以資料列為基礎的日誌記錄格式和 --binlog-do-db=sales 時，以下 UPDATE 所做的變更不會被記錄

USE prices;
UPDATE prices.march SET amount=amount-25;

即使 USE prices 陳述式變更為 USE sales，UPDATE 陳述式的效果仍不會寫入二進制日誌。

與以陳述式為基礎的日誌記錄相比，在處理 --binlog-do-db 時，以資料列為基礎的日誌記錄還有另一個重要的差異，該差異發生在參照多個資料庫的陳述式中。假設伺服器啟動時使用 --binlog-do-db=db1，並且執行以下陳述式

USE db1;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

如果您使用以陳述式為基礎的日誌記錄，則對兩個資料表的更新都會寫入二進制日誌。但是，當使用以資料列為基礎的格式時，只會記錄對 table1 的變更；table2 位於不同的資料庫中，因此它不會被 UPDATE 變更。現在假設，USE db4 陳述式而不是 USE db1 陳述式

USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

在此情況下，使用基於語句的記錄時，UPDATE 陳述式不會寫入二進位日誌。但是，當使用基於列的記錄時，對 table1 的變更會被記錄，但對 table2 的變更則不會記錄 — 換句話說，只有在 --binlog-do-db 指定的資料庫中的表格變更才會被記錄，而預設資料庫的選擇對此行為沒有影響。

--binlog-ignore-db=db_name

此選項對二進位日誌的影響，類似於 --replicate-ignore-db 對複寫的影響。

此選項的效果取決於目前使用的是基於語句的記錄格式還是基於列的記錄格式，如同 --replicate-ignore-db 的效果取決於目前使用的是基於語句的複寫還是基於列的複寫一樣。您應該記住，用於記錄給定陳述式的格式不一定與 binlog_format 的值所指示的格式相同。例如，諸如 CREATE TABLE 和 ALTER TABLE 之類的 DDL 陳述式始終會以語句的形式記錄，而不管生效的記錄格式如何，因此，以下關於 --binlog-ignore-db 的基於語句的規則始終適用於判斷是否記錄陳述式。

基於語句的記錄。 告知伺服器不要記錄任何預設資料庫（也就是由 USE 選取的資料庫）為 db_name 的陳述式。

當沒有預設資料庫時，不會套用任何 --binlog-ignore-db 選項，且此類陳述式始終會被記錄。（Bug #11829838, Bug #60188）

基於列的格式。 告知伺服器不要記錄對資料庫 db_name 中任何表格的更新。目前資料庫沒有影響。

當使用基於語句的記錄時，以下範例的行為可能與您預期的不同。假設伺服器以 --binlog-ignore-db=sales 啟動，並且您發出以下陳述式：

USE prices;
UPDATE sales.january SET amount=amount+1000;

在這種情況下，UPDATE 陳述式會被記錄，因為 --binlog-ignore-db 僅適用於預設資料庫（由 USE 陳述式決定）。因為陳述式中明確指定了 sales 資料庫，所以該陳述式未被篩選。但是，當使用基於列的記錄時，UPDATE 陳述式的影響不會被寫入二進位日誌，這表示不會記錄對 sales.january 表格的任何變更；在此實例中，--binlog-ignore-db=sales 會導致對於二進位日誌記錄而言，所有對來源副本的 sales 資料庫中表格所做的變更都會被忽略。

若要指定要忽略的多個資料庫，請多次使用此選項，每個資料庫使用一次。因為資料庫名稱可能包含逗號，如果您提供以逗號分隔的清單，則該清單會被視為單一資料庫的名稱。

如果您使用跨資料庫更新，並且不希望記錄這些更新，則不應使用此選項。

--binlog-checksum={NONE|CRC32}

啟用此選項會導致來源針對寫入二進位日誌的事件寫入校驗和。設定為 NONE 以停用，或設定為用於產生校驗和的演算法名稱；目前僅支援 CRC32 校驗和，且 CRC32 是預設值。您無法在交易內變更此選項的設定。

--max-binlog-dump-events=N

此選項由 MySQL 測試套件內部用於複寫測試和偵錯。

--sporadic-binlog-dump-fail

此選項由 MySQL 測試套件內部用於複寫測試和偵錯。

binlog_cache_size

在交易期間保留二進位日誌變更的記憶體緩衝區大小。

當在伺服器上啟用二進位日誌記錄時（log_bin 系統變數設定為 ON），如果伺服器支援任何交易儲存引擎，則會為每個用戶端配置一個二進位日誌快取。如果交易的資料超過記憶體緩衝區中的空間，則多餘的資料會儲存在暫存檔中。當伺服器上啟用二進位日誌加密時，記憶體緩衝區不會加密，但用於保留二進位日誌快取的任何暫存檔都會加密。在每次交易提交後，會透過清除記憶體緩衝區和截斷暫存檔（如果已使用）來重設二進位日誌快取。

如果您經常使用大型交易，則可以增加此快取大小，以減少或消除寫入暫存檔的需求，從而獲得更好的效能。Binlog_cache_use 和 Binlog_cache_disk_use 狀態變數可用於調整此變數的大小。請參閱第 7.4.4 節「二進位日誌」。

binlog_cache_size 僅設定交易快取的大小；語句快取的大小由 binlog_stmt_cache_size 系統變數控管。

binlog_checksum

啟用後，此變數會導致來源為二進位日誌中的每個事件寫入校驗和。binlog_checksum 支援值 NONE（停用校驗和）和 CRC32。預設值為 CRC32。當 binlog_checksum 停用時（值為 NONE），伺服器會透過寫入和檢查每個事件的事件長度（而非校驗和），來驗證它只將完整的事件寫入二進位日誌。

在來源上將此變數設定為複本無法辨識的值，會導致複本將其自己的 binlog_checksum 值設定為 NONE，並停止複寫且出現錯誤。如果擔心與舊版複本的回溯相容性，您可能需要明確將值設定為 NONE。

MySQL 8.4 中的群組複寫支援校驗和，因此群組成員可以使用預設設定。

變更 binlog_checksum 的值會導致二進位日誌輪換，因為校驗和必須針對整個二進位日誌檔寫入，而絕不能僅針對其中一部分寫入。您無法在交易內變更 binlog_checksum 的值。

當使用 binlog_transaction_compression 系統變數啟用二進位日誌交易壓縮時，不會為壓縮交易酬載中的個別事件寫入校驗和。而是為 GTID 事件寫入校驗和，並為壓縮的 Transaction_payload_event 寫入校驗和。

binlog_direct_non_transactional_updates

由於並行問題，當交易包含對交易和非交易表格的更新時，複本可能會變得不一致。MySQL 嘗試透過將非交易陳述式寫入交易快取來保留這些陳述式之間的因果關係，該交易快取會在提交時清除。但是，當代表交易對非交易表格所做的修改立即對其他連線可見時，會出現問題，因為這些變更可能不會立即寫入二進位日誌。

binlog_direct_non_transactional_updates 變數提供了一種可能的解決方案。預設情況下，此變數已停用。啟用 binlog_direct_non_transactional_updates 會導致對非交易表格的更新直接寫入二進位日誌，而不是寫入交易快取。

設定此系統變數的 Session 值是受限的操作。Session 使用者必須擁有足夠的權限來設定受限的 Session 變數。請參閱第 7.1.9.1 節，「系統變數權限」。

binlog_direct_non_transactional_updates 僅適用於使用基於語句的二進制日誌格式複製的語句；也就是說，它僅在 binlog_format 的值為 STATEMENT 時，或當 binlog_format 為 MIXED 且給定的語句使用基於語句的格式複製時才有效。當二進制日誌格式為 ROW 時，或當 binlog_format 設定為 MIXED 且給定的語句使用基於行的格式複製時，此變數無效。

當二進制日誌格式為 ROW 或 MIXED 時，此變數無效。

binlog_encryption

啟用此伺服器上二進制日誌檔案和中繼日誌檔案的加密。OFF 是預設值。ON 設定二進制日誌檔案和中繼日誌檔案的加密。二進制日誌記錄不需要在伺服器上啟用即可啟用加密，因此您可以在沒有二進制日誌的副本上加密中繼日誌檔案。若要使用加密，必須安裝並設定金鑰環外掛程式，以提供 MySQL 伺服器的金鑰環服務。有關如何執行此操作的說明，請參閱第 8.4.4 節，「MySQL 金鑰環」。任何支援的金鑰環外掛程式都可以用於儲存二進制日誌加密金鑰。

當您首次啟用二進制日誌加密啟動伺服器時，會在初始化二進制日誌和中繼日誌之前產生新的二進制日誌加密金鑰。此金鑰用於加密每個二進制日誌檔案（如果伺服器已啟用二進制日誌記錄）和中繼日誌檔案（如果伺服器具有複製通道）的檔案密碼，而從檔案密碼產生的進一步金鑰則用於加密檔案中的資料。中繼日誌檔案會針對所有通道加密，包括群組複製應用程式通道和在啟用加密後建立的新通道。二進制日誌索引檔案和中繼日誌索引檔案永遠不會加密。

如果您在伺服器執行時啟用加密，則此時會產生新的二進制日誌加密金鑰。例外情況是，如果先前在伺服器上啟用了加密，然後又停用了，則會再次使用之前使用的二進制日誌加密金鑰。二進制日誌檔案和中繼日誌檔案會立即輪換，並且使用此二進制日誌加密金鑰加密新檔案和所有後續二進制日誌檔案和中繼日誌檔案的檔案密碼。伺服器上仍然存在的現有二進制日誌檔案和中繼日誌檔案不會自動加密，但您可以清除不再需要的檔案。

如果您將 binlog_encryption 系統變數變更為 OFF 來停用加密，二進制日誌檔案和中繼日誌檔案會立即輪換，而所有後續日誌記錄都不會加密。先前加密的檔案不會自動解密，但伺服器仍然能夠讀取它們。需要 BINLOG_ENCRYPTION_ADMIN 權限（或已棄用的 SUPER 權限）才能在伺服器執行時啟用或停用加密。群組複製應用程式通道不包含在中繼日誌輪換請求中，因此這些通道的未加密日誌記錄要等到它們的日誌在正常使用中輪換後才會開始。

有關二進制日誌檔案和中繼日誌檔案加密的更多資訊，請參閱第 19.3.2 節，「加密二進制日誌檔案和中繼日誌檔案」。

binlog_error_action

控制當伺服器遇到錯誤時會發生什麼情況，例如無法寫入、刷新或同步二進制日誌，這可能會導致來源的二進制日誌不一致，並導致副本失去同步。

此變數預設為 ABORT_SERVER，這會使伺服器在遇到二進制日誌的此類錯誤時停止記錄並關閉。重新啟動時，復原程序會像發生意外伺服器停止的情況一樣（請參閱第 19.4.2 節，「處理副本的意外停止」）。

當 binlog_error_action 設定為 IGNORE_ERROR 時，如果伺服器遇到此類錯誤，它會繼續進行中的交易，記錄錯誤，然後停止記錄，並繼續執行更新。若要恢復二進制日誌記錄，必須再次啟用 log_bin，這需要重新啟動伺服器。此設定提供與較舊版本的 MySQL 的向後相容性。

binlog_expire_logs_seconds

以秒為單位設定二進制日誌的到期時間。到期時間結束後，可以自動移除二進制日誌檔案。可能的移除發生在啟動時和刷新二進制日誌時。日誌刷新的發生方式如第 7.4 節，「MySQL 伺服器日誌」所示。

二進制日誌的預設到期時間為 2592000 秒，等於 30 天（30*24*60*60 秒）。

可以將 binlog_expire_logs_auto_purge 系統變數設定為 OFF 來停用二進制日誌的自動清除。這會優先於 binlog_expire_logs_seconds 的任何設定。

若要手動移除二進制日誌檔案，請使用 PURGE BINARY LOGS 陳述式。請參閱第 15.4.1.1 節，「PURGE BINARY LOGS 陳述式」。

binlog_expire_logs_auto_purge

啟用或停用自動清除二進制日誌檔案。將此變數設定為 ON（預設值）會啟用自動清除；將其設定為 OFF 會停用自動清除。清除前等待的時間間隔由 binlog_expire_logs_seconds 控制。

此變數對 PURGE BINARY LOGS 無效。

binlog_format

此系統變數設定二進制日誌記錄格式，可以是 STATEMENT、ROW 或 MIXED 中的任何一個。（請參閱第 19.2.1 節，「複製格式」。）當伺服器上啟用二進制日誌記錄時，設定才會生效，也就是當 log_bin 系統變數設定為 ON 時。在 MySQL 8.4 中，預設會啟用二進制日誌記錄，且預設使用基於行的格式。

可以在啟動時或執行時設定 binlog_format，但如稍後所述，在某些情況下，無法在執行時變更此變數，或導致複製失敗。

預設值為 ROW。例外情況：在 NDB Cluster 中，預設值為 MIXED；NDB Cluster 不支援基於語句的複製。

設定此系統變數的 Session 值是受限的操作。Session 使用者必須擁有足夠的權限來設定受限的 Session 變數。請參閱第 7.1.9.1 節，「系統變數權限」。

管理此變數變更何時生效以及效果持續多久的規則，與其他 MySQL 伺服器系統變數相同。有關更多資訊，請參閱第 15.7.6.1 節，「設定變數指派的語法」。

指定 MIXED 時，會使用基於語句的複製，但保證只有基於行的複製才能產生正確結果的情況除外。例如，當語句包含可載入的函式或 UUID() 函式時，就會發生這種情況。

有關設定每個二進制日誌記錄格式時如何處理預存程式（預存程序和函式、觸發程序和事件）的詳細資訊，請參閱第 27.7 節，「預存程式二進制日誌記錄」。

在某些情況下，您無法在執行時切換複製格式

嘗試在任何這些情況下切換複製格式（或嘗試設定目前的複製格式）都會導致錯誤。但是，您可以使用 PERSIST_ONLY (SET @@PERSIST_ONLY.binlog_format) 隨時變更複製格式，因為此動作不會修改執行時全域系統變數值，並且僅在重新啟動伺服器後才會生效。

當存在任何暫存資料表時，不建議在執行時切換複製格式，因為僅在使用基於語句的複製時才會記錄暫存資料表，而在使用基於行的複製和混合複製時，則不會記錄它們。

變更複製來源伺服器上的日誌格式，不會導致副本的日誌格式也隨之變更。如果在複製正在進行時切換複製格式，可能會導致問題，如果副本啟用了二進位日誌，且變更導致副本使用 STATEMENT 格式的日誌，而來源卻使用 ROW 或 MIXED 格式的日誌。副本無法將接收到的 ROW 日誌格式二進位日誌項目轉換為 STATEMENT 格式，以便在自己的二進位日誌中使用，因此這種情況可能會導致複製失敗。如需更多資訊，請參閱 第 7.4.4.2 節，「設定二進位日誌格式」。

二進位日誌格式會影響下列伺服器選項的行為

這些影響會在各個選項的說明中詳細討論。

binlog_group_commit_sync_delay

控制二進位日誌提交在將二進位日誌檔案同步到磁碟之前等待的微秒數。預設情況下，binlog_group_commit_sync_delay 設定為 0，表示沒有延遲。將 binlog_group_commit_sync_delay 設定為微秒延遲，可以讓更多交易同時同步到磁碟，從而減少提交一組交易的整體時間，因為較大的群組每個群組需要較少的時間單位。

當設定 sync_binlog=0 或 sync_binlog=1 時，由 binlog_group_commit_sync_delay 指定的延遲將在每次二進位日誌提交群組同步之前（或在 sync_binlog=0 的情況下，在繼續之前）應用。當 sync_binlog 設定為大於 1 的值 n 時，延遲會在每 n 個二進位日誌提交群組之後應用。

設定 binlog_group_commit_sync_delay 可以增加任何具有（或在容錯移轉後可能具有）副本的伺服器上並行提交交易的數量，因此可以增加副本上的並行執行。若要從此效果中受益，副本伺服器必須設定 replica_parallel_type=LOGICAL_CLOCK。設定 binlog_group_commit_sync_delay 時，請務必考量來源和副本的輸送量。

設定 binlog_group_commit_sync_delay 也可以減少任何具有二進位日誌的伺服器（來源或副本）上對二進位日誌的 fsync() 呼叫次數。

請注意，設定 binlog_group_commit_sync_delay 會增加伺服器上交易的延遲時間，這可能會影響用戶端應用程式。此外，在高並行工作負載下，延遲可能會增加競爭，從而降低輸送量。通常，設定延遲的好處大於缺點，但應始終進行調整以確定最佳設定。

binlog_group_commit_sync_no_delay_count

在中止 binlog_group_commit_sync_delay 指定的目前延遲之前，要等待的最大交易數。如果 binlog_group_commit_sync_delay 設定為 0，則此選項沒有任何效果。

binlog_max_flush_queue_time

binlog_max_flush_queue_time 已棄用，並標記為在未來的 MySQL 版本中最終移除。以前，此系統變數控制從刷新佇列讀取交易以繼續進行群組提交的微秒時間。它不再有任何效果。

binlog_order_commits

當在複製來源伺服器上啟用此變數時（這是預設值），發送至儲存引擎的交易提交指令會在單一執行緒上序列化，以便交易始終以寫入二進位日誌的相同順序提交。停用此變數允許使用多個執行緒發送交易提交指令。與二進位日誌群組提交結合使用時，這可以防止單一交易的提交速率成為輸送量的瓶頸，因此可能會產生效能提升。

當所有涉及的儲存引擎都確認交易已準備好提交時，交易會寫入二進位日誌。然後，二進位日誌群組提交邏輯會在二進位日誌寫入完成後提交一組交易。當停用 binlog_order_commits 時，由於此程序使用多個執行緒，因此提交群組中的交易可能會以與它們在二進位日誌中的順序不同的順序提交。（來自單一用戶端的交易始終按時間順序提交。）在許多情況下，這並不重要，因為在個別交易中執行的操作應產生一致的結果，如果不是這種情況，則應改為使用單一交易。

如果您想要確保來源和多執行緒副本上的交易歷史記錄保持相同，請在副本上設定 replica_preserve_commit_order=1。

binlog_rotate_encryption_master_key_at_startup

指定是否在伺服器啟動時輪換二進位日誌主金鑰。二進位日誌主金鑰是二進位日誌加密金鑰，用於加密伺服器上二進位日誌檔案和中繼日誌檔案的檔案密碼。當首次在啟用二進位日誌加密的情況下啟動伺服器時（binlog_encryption=ON），會產生新的二進位日誌加密金鑰並用作二進位日誌主金鑰。如果 binlog_rotate_encryption_master_key_at_startup 系統變數也設定為 ON，則每次重新啟動伺服器時，都會產生另一個二進位日誌加密金鑰，並用作所有後續二進位日誌檔案和中繼日誌檔案的二進位日誌主金鑰。如果 binlog_rotate_encryption_master_key_at_startup 系統變數設定為 OFF（這是預設值），則在伺服器重新啟動後會再次使用現有的二進位日誌主金鑰。如需有關二進位日誌加密金鑰和二進位日誌主金鑰的更多資訊，請參閱 第 19.3.2 節，「加密二進位日誌檔案和中繼日誌檔案」。

binlog_row_event_max_size

當使用以列為基礎的二進位日誌時，此設定是以列為基礎的二進位日誌事件的最大大小（以位元組為單位）的軟性限制。如果可能，二進位日誌中儲存的列會分組到大小不超過此設定值的事件中。如果事件無法分割，則可能會超過最大大小。預設值為 8192 位元組。

此全域系統變數為唯讀，且只能在伺服器啟動時設定。因此，其值只能透過將 PERSIST_ONLY 關鍵字或 @@persist_only 限定詞與 SET 陳述式搭配使用來修改。

binlog_row_image

對於 MySQL 以列為基礎的複製，此變數決定如何將列影像寫入二進位日誌。

設定此系統變數的 Session 值是受限的操作。Session 使用者必須擁有足夠的權限來設定受限的 Session 變數。請參閱第 7.1.9.1 節，「系統變數權限」。

在 MySQL 以列為基礎的複製中，每個列變更事件都包含兩個影像，一個「之前」影像，其欄位在搜尋要更新的列時會與之比對，以及一個包含變更的「之後」影像。通常，MySQL 會記錄完整列（也就是所有欄位），以作為之前和之後的影像。但是，嚴格來說，並非必須在兩個影像中都包含每個欄位，而且我們通常可以透過僅記錄實際需要的欄位來節省磁碟、記憶體和網路使用量。

對於前置影像（before image），只需要記錄能唯一識別資料列的最小欄位集合。如果包含該資料列的資料表有主鍵，則只會將主鍵欄位或多個欄位寫入二進位日誌。否則，如果資料表具有唯一鍵，且其所有欄位都為 NOT NULL，則只需要記錄唯一鍵中的欄位。（如果資料表既沒有主鍵，也沒有任何 NULL 欄位的唯一鍵，則必須在前置影像中使用並記錄所有欄位。）在後置影像（after image）中，只需要記錄實際已變更的欄位。

您可以使用 binlog_row_image 系統變數，使伺服器記錄完整或最少的資料列。此變數實際上會採用三個可能值之一，如下列所示：

預設值為 full。

當使用 minimal 或 noblob 時，如果來源資料表和目標資料表都符合下列條件，則保證刪除和更新可以正確運作：

（換句話說，資料表必須相同，除了非資料表主鍵一部分的索引之外。）

如果未滿足這些條件，則目標資料表中的主鍵欄位值可能不足以提供刪除或更新的唯一比對。在這種情況下，不會發出警告或錯誤；來源和複本會無聲地分歧，從而破壞一致性。

當二進位日誌格式為 STATEMENT 時，設定此變數無效。當 binlog_format 為 MIXED 時，binlog_row_image 的設定會套用至使用以列為基礎的格式記錄的變更，但此設定對以陳述式記錄的變更無效。

在全域或工作階段層級設定 binlog_row_image 不會導致隱含的 commit；這表示此變數可以在交易進行時變更，而不會影響交易。

binlog_row_metadata

設定在使用以列為基礎的日誌記錄時，新增至二進位日誌的資料表元資料數量。設定為 MINIMAL (預設值) 時，只會記錄與 SIGNED 旗標、欄位字元集和幾何類型相關的中繼資料。設定為 FULL 時，會記錄資料表的完整元資料，例如欄位名稱、ENUM 或 SET 字串值、PRIMARY KEY 資訊等等。

擴充的元資料用於以下目的：

binlog_row_value_options

設定為 PARTIAL_JSON 時，這會針對僅修改 JSON 文件一小部分的更新啟用空間效率高的二進位日誌格式，這會導致以列為基礎的複寫僅將 JSON 文件的修改部分寫入二進位日誌中更新的後置影像，而不是寫入完整的文件（請參閱JSON 值的部份更新）。這適用於使用任何 JSON_SET()、JSON_REPLACE() 和 JSON_REMOVE() 序列修改 JSON 欄位的 UPDATE 陳述式。如果伺服器無法產生部份更新，則會改為使用完整文件。

預設值為空字串，這會停用格式的使用。若要取消設定 binlog_row_value_options 並還原為寫入完整 JSON 文件，請將其值設定為空字串。

設定此系統變數的 Session 值是受限的操作。Session 使用者必須擁有足夠的權限來設定受限的 Session 變數。請參閱第 7.1.9.1 節，「系統變數權限」。

binlog_row_value_options=PARTIAL_JSON 僅在啟用二進位日誌記錄且 binlog_format 設定為 ROW 或 MIXED 時才會生效。以陳述式為基礎的複寫始終僅記錄 JSON 文件的修改部分，無論為 binlog_row_value_options 設定的任何值為何。為了最大化節省的空間，請將 binlog_row_image=NOBLOB 或 binlog_row_image=MINIMAL 與此選項一起使用。binlog_row_image=FULL 比這兩者節省的空間都少，因為完整 JSON 文件儲存在前置影像中，而部分更新僅儲存在後置影像中。

mysqlbinlog 輸出包含以 base-64 字串編碼的形式呈現的部分 JSON 更新，使用 BINLOG 陳述式。如果指定 --verbose 選項，mysqlbinlog 會使用虛擬 SQL 陳述式以可讀取的 JSON 格式顯示部分 JSON 更新。

如果無法將修改套用至複本上的 JSON 文件，MySQL 複寫會產生錯誤。這包括找不到路徑的錯誤。請注意，即使有此和其他安全檢查，如果複本上的 JSON 文件與來源上的文件分歧，並且套用了部分更新，理論上仍可能在複本上產生有效但非預期的 JSON 文件。

binlog_rows_query_log_events

此系統變數僅影響以列為基礎的日誌記錄。啟用時，它會導致伺服器將資訊性日誌事件（例如資料列查詢日誌事件）寫入其二進位日誌中。此資訊可用於偵錯和相關目的，例如在無法從資料列更新重建時，取得來源上發出的原始查詢。

設定此系統變數的 Session 值是受限的操作。Session 使用者必須擁有足夠的權限來設定受限的 Session 變數。請參閱第 7.1.9.1 節，「系統變數權限」。

這些資訊性事件通常會被讀取二進位日誌的 MySQL 程式忽略，因此在從備份複寫或還原時不會造成問題。若要檢視它們，請使用 mysqlbinlog 的 --verbose 選項兩次，以 -vv 或 --verbose --verbose 的形式，來增加詳細程度。

binlog_stmt_cache_size

二進位日誌的記憶體緩衝區大小，用於保存交易期間發出的非交易性陳述式。

如果在伺服器上啟用二進位日誌記錄（將 log_bin 系統變數設定為 ON），如果伺服器支援任何交易性儲存引擎，則會為每個用戶端分配個別的二進位日誌交易和陳述式快取。如果交易中使用的非交易性陳述式資料超過記憶體緩衝區中的空間，則多餘的資料會儲存在暫存檔中。當二進位日誌加密在伺服器上處於作用中時，記憶體緩衝區不會加密，但用於保存二進位日誌快取的任何暫存檔都會加密。在每次交易提交後，二進位日誌陳述式快取會透過清除記憶體緩衝區和截斷暫存檔（如果已使用）來重設。

如果您在交易期間經常使用大型的非交易性陳述式，您可以增加此快取大小，藉由減少或消除寫入暫存檔的需求來獲得更好的效能。Binlog_stmt_cache_use 和 Binlog_stmt_cache_disk_use 狀態變數可用於調整此變數的大小。請參閱第 7.4.4 節，"二進位日誌"。

binlog_cache_size 系統變數設定交易快取的大小。

binlog_transaction_compression

啟用此伺服器上寫入二進位日誌檔的交易壓縮功能。預設值為 OFF。使用 binlog_transaction_compression_level_zstd 系統變數來設定用於壓縮的 zstd 演算法的壓縮層級。

設定 binlog_transaction_compression 不會立即生效，而是適用於所有後續的 START REPLICA 陳述式。

當啟用二進位日誌交易壓縮時，交易酬載會被壓縮，然後以單一事件（Transaction_payload_event）寫入二進位日誌檔。壓縮後的交易酬載在以複製串流傳送到副本、其他群組複製群組成員或諸如 mysqlbinlog 之類的用戶端時，會保持壓縮狀態，並以壓縮狀態寫入中繼日誌。因此，二進位日誌交易壓縮可節省交易發起者和接收者（及其備份）的儲存空間，並在伺服器實例之間傳送交易時節省網路頻寬。

若要使 binlog_transaction_compression=ON 直接生效，則必須在伺服器上啟用二進位日誌記錄。當 MySQL 8.4 伺服器實例沒有二進位日誌時，無論其 binlog_transaction_compression 的值為何，它都可以接收、處理和顯示壓縮的交易酬載。此類伺服器實例接收的壓縮交易酬載會以壓縮狀態寫入中繼日誌，因此它們間接受益於複製拓撲中其他伺服器執行的壓縮。

此系統變數無法在交易內容中變更。設定此系統變數的工作階段值是受限制的操作。工作階段使用者必須擁有足夠的權限才能設定受限制的工作階段變數。請參閱第 7.1.9.1 節「系統變數權限」。

如需有關二進位日誌交易壓縮的更多資訊，包括哪些事件會壓縮以及哪些事件不會壓縮的詳細資訊，以及使用交易壓縮時的行為變更，請參閱第 7.4.4.5 節「二進位日誌交易壓縮」。

您可以使用 ndb_log_transaction_compression 系統變數為 NDB 啟用此功能。此外，在命令列或 my.cnf 檔案中設定 --binlog-transaction-compression=ON 會在伺服器啟動時啟用 ndb_log_transaction_compression。請參閱變數說明以取得更多資訊。

binlog_transaction_compression_level_zstd

設定此伺服器上二進位日誌交易壓縮的壓縮層級，此壓縮層級由 binlog_transaction_compression 系統變數啟用。此值是一個整數，決定壓縮工作量，從 1（最低工作量）到 22（最高工作量）。如果您未指定此系統變數，則壓縮層級設定為 3。

設定 binlog_transaction_compression_level_zstd 不會立即生效，而是適用於所有後續的 START REPLICA 陳述式。

隨著壓縮層級的提高，資料壓縮率會提高，這會減少交易酬載所需的儲存空間和網路頻寬。但是，資料壓縮所需的工作量也會增加，從而占用發起伺服器上的時間、CPU 和記憶體資源。壓縮工作量的增加與資料壓縮率的增加沒有線性關係。

此系統變數無法在交易內容中變更。設定此系統變數的工作階段值是受限制的操作。工作階段使用者必須擁有足夠的權限才能設定受限制的工作階段變數。請參閱第 7.1.9.1 節「系統變數權限」。

此變數對 NDB 資料表的交易記錄沒有影響；請改用 ndb_log_transaction_compression_level_zstd。

binlog_transaction_dependency_history_size

設定記憶體中保留並用於查詢上次修改給定資料列的交易的資料列雜湊數量上限。達到此雜湊數量後，便會清除歷史記錄。

log_bin

顯示伺服器上二進位日誌記錄的狀態，啟用 (ON) 或停用 (OFF)。啟用二進位日誌記錄後，伺服器會將所有變更資料的陳述式記錄到二進位日誌中，用於備份和複寫。ON 表示二進位日誌可用，OFF 表示未使用。 --log-bin 選項可用於指定二進位日誌的基礎名稱和位置。

在較早的 MySQL 版本中，二進位日誌記錄預設為停用，如果您指定 --log-bin 選項，則會啟用二進位日誌記錄。二進位日誌記錄預設為啟用，無論您是否指定 --log-bin 選項，log_bin 系統變數都會設定為 ON。例外情況是，如果您使用 mysqld 透過使用 --initialize 或 --initialize-insecure 選項來手動初始化資料目錄，則二進位日誌記錄預設為停用。在這種情況下，可以透過指定 --log-bin 選項來啟用二進位日誌記錄。

如果在啟動時指定 --skip-log-bin 或 --disable-log-bin 選項，則會停用二進位日誌記錄，並且 log_bin 系統變數會設定為 OFF。如果指定其中任一選項，並且也指定 --log-bin，則稍後指定的選項會優先。

有關二進制日誌的格式和管理資訊，請參閱第 7.4.4 節，「二進制日誌」。

log_bin_basename

保留二進位日誌檔的基礎名稱和路徑，可以使用 --log-bin 伺服器選項設定。最大變數長度為 256。在 MySQL 8.4 中，如果未提供 --log-bin 選項，則預設基礎名稱為 binlog。為了與 MySQL 5.7 相容，如果 --log-bin 選項未提供字串或提供了空字串，則預設基礎名稱為 host_name-bin，使用主機的名稱。預設位置為資料目錄。

log_bin_index

保留二進位日誌索引檔的基礎名稱和路徑，可以使用 --log-bin-index 伺服器選項設定。最大變數長度為 256。

log_bin_trust_function_creators

此變數在啟用二進位日誌記錄時適用。它控制是否可以信任儲存函數建立者不會建立可能會導致不安全事件寫入二進位日誌的儲存函數。如果設定為 0（預設值），除非使用者除了擁有 CREATE ROUTINE 或 ALTER ROUTINE 權限之外，還擁有 SUPER 權限，否則不允許他們建立或變更儲存函數。設定為 0 也會強制執行一個限制，即函數必須使用 DETERMINISTIC 特性宣告，或者使用 READS SQL DATA 或 NO SQL 特性宣告。如果變數設定為 1，則 MySQL 不會對儲存函數建立強制執行這些限制。此變數也適用於觸發程序建立。請參閱第 27.7 節「儲存程式二進位日誌記錄」。

log_replica_updates

log_replica_updates 指定是否應將副本伺服器從複寫來源伺服器接收的更新記錄到副本自己的二進位日誌中。

啟用此變數會導致複本將從來源接收並由複寫 SQL 執行緒執行的更新寫入複本自己的二進制日誌。二進制日誌記錄由 --log-bin 選項控制，且預設為啟用，複本也必須啟用二進制日誌記錄才能記錄更新。請參閱第 19.1.6 節「複寫和二進制日誌記錄選項和變數」。log_replica_updates 預設為啟用，除非您指定 --skip-log-bin 停用二進制日誌記錄，在這種情況下，MySQL 也預設停用複本更新日誌記錄。如果您需要在啟用二進制日誌記錄時停用複本更新日誌記錄，請在複本伺服器啟動時指定 --log-replica-updates=OFF。

啟用 log_replica_updates 可讓複寫伺服器鏈接在一起。例如，您可能想要使用此配置設定複寫伺服器

A -> B -> C

在此，A 作為複本 B 的來源，而 B 作為複本 C 的來源。為了使此配置生效，B 必須同時作為來源 和 複本。在啟用二進制日誌記錄且 log_replica_updates 已啟用的情況下（預設設定），從 A 收到的更新將由 B 記錄到其二進制日誌中，因此可以傳遞到 C。

log_slave_updates

已棄用的 log_replica_updates 別名。

log_statements_unsafe_for_binlog

如果遇到錯誤 1592，則控制是否將產生的警告新增至錯誤日誌。

master_verify_checksum

已棄用的 source_verify_checksum 別名。

max_binlog_cache_size

如果交易需要超過此數量的位元組，伺服器會產生 Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage 錯誤。當 gtid_mode 不是 ON 時，建議的最大值為 4GB，原因是在這種情況下，MySQL 無法處理大於 4GB 的二進制日誌位置；當 gtid_mode 為 ON 時，此限制不適用，並且伺服器可以處理任意大小的二進制日誌位置。

如果由於 gtid_mode 不是 ON，或是由於其他原因，您需要保證二進制日誌不超過給定的大小 maxsize，則應根據此處顯示的公式設定此變數

max_binlog_cache_size < 
  (((maxsize - max_binlog_size) / max_connections) - 1000) / 1.2

此計算會考慮以下情況

max_binlog_cache_size 僅設定交易快取的大小；語句快取的上限由 max_binlog_stmt_cache_size 系統變數控制。

max_binlog_cache_size 對於工作階段的可見性與 binlog_cache_size 系統變數的可見性相符；換句話說，變更其值僅會影響在值變更後啟動的新工作階段。

max_binlog_size

如果寫入二進制日誌導致目前的日誌檔案大小超過此變數的值，則伺服器會輪換二進制日誌（關閉目前的檔案並開啟下一個檔案）。最小值為 4096 位元組。最大值和預設值為 1GB。加密的二進制日誌檔案具有額外的 512 位元組標頭，該標頭包含在 max_binlog_size 中。

交易會以一個區塊寫入二進制日誌，因此永遠不會在多個二進制日誌之間分割。因此，如果您有大型交易，您可能會看到二進制日誌檔案大於 max_binlog_size。

如果 max_relay_log_size 為 0，則 max_binlog_size 的值也適用於中繼日誌。

在伺服器上使用 GTID 時，當達到 max_binlog_size 時，如果無法存取系統資料表 mysql.gtid_executed 來寫入目前二進制日誌檔案的 GTID，則無法輪換二進制日誌。在這種情況下，伺服器會根據其 binlog_error_action 設定做出回應。如果設定了 IGNORE_ERROR，則會在伺服器上記錄錯誤並停止二進制日誌記錄；如果設定了 ABORT_SERVER，則伺服器會關閉。

max_binlog_stmt_cache_size

如果交易中的非交易性語句需要超過此數量的記憶體位元組，則伺服器會產生錯誤。最小值為 4096。最大值和預設值在 32 位元平台上為 4GB，在 64 位元平台上為 16EB (exabytes)。

max_binlog_stmt_cache_size 僅設定語句快取的大小；交易快取的上限完全由 max_binlog_cache_size 系統變數控制。

original_commit_timestamp

供複寫內部使用。在複本上重新執行交易時，此設定為交易在原始來源上提交的時間，以自 epoch 以來的微秒為單位。這允許原始提交時間戳記在整個複寫拓樸中傳播。

設定此系統變數的工作階段值是受限制的操作。工作階段使用者必須具有 REPLICATION_APPLIER 權限（請參閱第 19.3.3 節「複寫權限檢查」），或具有設定受限制的工作階段變數的足夠權限（請參閱第 7.1.9.1 節「系統變數權限」）。但是，請注意，此變數不是供使用者設定的；它是由複寫基礎架構自動設定的。

source_verify_checksum

啟用 source_verify_checksum 會導致來源透過檢查總和檢查碼來驗證從二進制日誌讀取的事件，並在發生不符時停止並產生錯誤。source_verify_checksum 預設為停用；在這種情況下，來源會使用二進制日誌中的事件長度來驗證事件，以便僅從二進制日誌讀取完整事件。

sql_log_bin

此變數控制是否為目前工作階段啟用二進制日誌記錄（假設二進制日誌本身已啟用）。預設值為 ON。若要停用或啟用目前工作階段的二進制日誌記錄，請將工作階段 sql_log_bin 變數設定為 OFF 或 ON。

將此變數設定為 OFF 可讓工作階段在對您不希望複寫到複本的來源進行變更時暫時停用二進制日誌記錄。

設定此系統變數的 Session 值是受限的操作。Session 使用者必須擁有足夠的權限來設定受限的 Session 變數。請參閱第 7.1.9.1 節，「系統變數權限」。

無法在交易或子查詢中設定 sql_log_bin 的工作階段值。

將此變數設定為 OFF 會阻止將 GTID 指派給二進制日誌中的交易。如果您正在使用 GTID 進行複寫，則這表示即使稍後再次啟用二進制日誌記錄，從此處寫入日誌的 GTID 也不會說明在此期間發生的任何交易，因此實際上會遺失這些交易。

sync_binlog

控制 MySQL 伺服器將二進制日誌同步到磁碟的頻率。

為了在使用 InnoDB 和交易的複製設定中獲得最大的持久性和一致性，請使用這些設定