二進制日誌包含描述資料庫變更的「事件」，例如表格建立操作或表格資料的變更。它還包含可能已進行變更的陳述式事件 (例如，符合零列的 DELETE)，除非使用以列為基礎的日誌記錄。二進制日誌還包含有關每個更新資料的陳述式所花費時間的資訊。二進制日誌有兩個重要用途

二進制日誌不適用於未修改資料的陳述式，例如 SELECT 或 SHOW。若要記錄所有陳述式 (例如，為了識別問題查詢)，請使用一般查詢日誌。請參閱第 7.4.3 節，「一般查詢日誌」。

啟用二進制日誌記錄來執行伺服器會使效能稍微變慢。但是，二進制日誌在啟用設定複寫和還原操作方面的優點通常會超過這個微小的效能降低。

二進制日誌具有對意外停止的彈性。只會記錄或讀回完整的事件或交易。

寫入二進制日誌的陳述式中的密碼會由伺服器重寫，使其不會以純文字形式逐字出現。另請參閱第 8.1.2.3 節，「密碼和日誌記錄」。

可以加密 MySQL 二進制日誌檔案和中繼日誌檔案，以協助保護這些檔案，以及它們所包含的潛在敏感資料，使其免受外部攻擊者的濫用，並防止儲存它們的作業系統使用者未經授權的檢視。您可以將 binlog_encryption 系統變數設定為 ON，以在 MySQL 伺服器上啟用加密。如需詳細資訊，請參閱第 19.3.2 節，「加密二進制日誌檔案和中繼日誌檔案」。

以下討論描述一些會影響二進位日誌運作的伺服器選項和變數。如需完整清單，請參閱第 19.1.6.4 節，「二進位日誌選項和變數」。

預設情況下會啟用二進位日誌（log_bin 系統變數設定為 ON）。例外情況是，如果您使用 mysqld 並透過呼叫 --initialize 或 --initialize-insecure 選項手動初始化資料目錄，則預設情況下會停用二進位日誌，但可以透過指定 --log-bin 選項來啟用。

若要停用二進位日誌，您可以在啟動時指定 --skip-log-bin 或 --disable-log-bin 選項。如果指定了其中任一選項，且同時也指定了 --log-bin，則稍後指定的選項會優先採用。

--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，則會發出警告或錯誤訊息。

--log-bin[=base_name] 選項用於指定二進位日誌檔案的基本名稱。如果您未提供 --log-bin 選項，MySQL 會使用 binlog 作為二進位日誌檔案的預設基本名稱。為了與較早的版本相容，如果您提供的 --log-bin 選項沒有字串或空字串，基本名稱預設為 host_name-bin，並使用主機名稱。建議您指定基本名稱，以便在主機名稱變更時，可以輕鬆繼續使用相同的二進位日誌檔名（請參閱第 B.3.7 節，「MySQL 中已知的問題」）。如果您在日誌名稱中提供副檔名（例如，--log-bin=base_name.extension），則會自動移除並忽略該副檔名。

mysqld 會在二進位日誌基本名稱後面附加數字副檔名，以產生二進位日誌檔名。每次伺服器建立新的日誌檔案時，數字都會增加，從而建立一系列排序的檔案。每當發生以下任一事件時，伺服器就會在此系列中建立新檔案：

如果您使用大型交易，則二進位日誌檔案可能會大於 max_binlog_size，因為交易會以一個整體寫入檔案，而不會在檔案之間分割。

為了追蹤已使用的二進位日誌檔案，mysqld 也會建立二進位日誌索引檔案，其中包含二進位日誌檔案的名稱。預設情況下，此檔案與二進位日誌檔案的基本名稱相同，並使用副檔名 '.index'。您可以使用 --log-bin-index[=file_name] 選項來變更二進位日誌索引檔案的名稱。在 mysqld 正在執行時，您不應手動編輯此檔案；否則會導致 mysqld 混淆。

術語「二進位日誌檔案」通常表示包含資料庫事件的個別編號檔案。術語「二進位日誌」統稱一組編號的二進位日誌檔案加上索引檔案。

二進位日誌檔案和二進位日誌索引檔案的預設位置是資料目錄。您可以使用 --log-bin 選項來指定替代位置，方法是在基本名稱中加入開頭的絕對路徑名稱，以指定不同的目錄。當伺服器從二進位日誌索引檔案讀取項目時，此檔案會追蹤已使用的二進位日誌檔案，並檢查項目是否包含相對路徑。如果包含，則會將路徑的相對部分替換為使用 --log-bin 選項設定的絕對路徑。記錄在二進位日誌索引檔案中的絕對路徑會保持不變；在這種情況下，必須手動編輯索引檔案，才能啟用新的路徑。二進位日誌檔案的基本名稱和任何指定的路徑，會以 log_bin_basename 系統變數提供。

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

具有足夠權限可設定受限工作階段系統變數的用戶端（請參閱第 7.1.9.1 節，「系統變數權限」）可以使用 SET sql_log_bin=OFF 陳述式來停用其自身語句的二進位日誌記錄。

預設情況下，伺服器會記錄事件的長度以及事件本身，並使用此資訊來驗證事件是否正確寫入。您也可以透過設定 binlog_checksum 系統變數，讓伺服器為事件寫入檢查碼。從二進位日誌讀回時，來源會預設使用事件長度，但如果啟用 source_verify_checksum，則可以使用可用的檢查碼。複寫 I/O（接收器）執行緒也會驗證從來源收到的事件。您可以透過啟用 replica_sql_verify_checksum，讓複寫 SQL（應用程式）執行緒在從中繼日誌讀取時使用可用的檢查碼。

記錄在二進位日誌中的事件格式取決於二進位日誌記錄格式。支援三種格式類型：以列為基礎的日誌記錄、以語句為基礎的日誌記錄和混合式日誌記錄。所使用的二進位日誌記錄格式取決於 MySQL 版本。如需日誌記錄格式的說明，請參閱第 7.4.4.1 節，「二進位日誌記錄格式」。

伺服器評估 --binlog-do-db 和 --binlog-ignore-db 選項的方式，與其評估 --replicate-do-db 和 --replicate-ignore-db 選項的方式相同。如需如何執行此操作的相關資訊，請參閱第 19.2.5.1 節，「資料庫層級複寫和二進位日誌記錄選項的評估」。

預設情況下，會啟用 log_replica_updates 來啟動複本，這表示複本會將從來源收到的任何資料修改寫入其自身的二進位日誌。必須啟用二進位日誌，此設定才能運作（請參閱第 19.1.6.3 節，「複本伺服器選項和變數」）。此設定讓複本可以作為其他複本的來源。

您可以使用 RESET BINARY LOGS AND GTIDS 陳述式來刪除所有二進位日誌檔案，或使用 PURGE BINARY LOGS 陳述式來刪除它們的子集。請參閱第 15.7.8.6 節，「RESET 陳述式」和第 15.4.1.1 節，「PURGE BINARY LOGS 陳述式」。

如果您使用的是 MySQL 複寫，則在您確定沒有複本仍需要使用舊的二進位日誌檔案之前，不應刪除來源上的舊二進位日誌檔案。例如，如果您的複本永遠不會落後三天以上，您可以每天在來源上執行 mysqladmin flush-logs binary，然後移除超過三天的任何日誌。您可以手動移除檔案，但最好使用 PURGE BINARY LOGS，這也會為您安全地更新二進位日誌索引檔案（而且可以採用日期引數）。請參閱第 15.4.1.1 節，「PURGE BINARY LOGS 陳述式」。

您可以使用 mysqlbinlog 公用程式顯示二進位日誌檔案的內容。當您想要重新處理日誌中的語句以進行復原操作時，這會很有用。例如，您可以按照如下方式從二進位日誌更新 MySQL 伺服器：

$> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog 也可用於顯示複本上中繼日誌檔案的內容，因為它們是使用與二進位日誌檔案相同的格式寫入的。如需 mysqlbinlog 公用程式及其使用方式的詳細資訊，請參閱第 6.6.9 節，「mysqlbinlog — 用於處理二進位日誌檔案的公用程式」。如需二進位日誌和復原操作的詳細資訊，請參閱第 9.5 節，「時間點（增量）復原」。

二進位日誌記錄會在語句或交易完成後立即進行，但在釋放任何鎖定或完成任何提交之前進行。這可確保日誌以提交順序記錄。

對非交易式資料表的更新會在執行後立即儲存在二進位日誌中。

在未提交的交易中，所有更新（UPDATE、DELETE 或 INSERT）變更交易表格（如 InnoDB 表格）的動作，都會被快取，直到伺服器收到 COMMIT 陳述式。屆時，mysqld 會在執行 COMMIT 之前，將整個交易寫入二進位日誌。

對非交易表格的修改無法回滾。如果回滾的交易包含對非交易表格的修改，則會在結尾處記錄整個交易和 ROLLBACK 陳述式，以確保這些表格的修改能夠被複製。

當處理交易的執行緒啟動時，它會分配一個 binlog_cache_size 大小的緩衝區來緩衝陳述式。如果陳述式大於此大小，則執行緒會開啟一個暫存檔來儲存交易。當執行緒結束時，該暫存檔會被刪除。如果伺服器上的二進位日誌加密已啟用，則暫存檔會被加密。

Binlog_cache_use 狀態變數顯示使用此緩衝區（可能還有暫存檔）來儲存陳述式的交易數量。Binlog_cache_disk_use 狀態變數顯示實際必須使用暫存檔的交易數量。這兩個變數可用於調整 binlog_cache_size，使其值足夠大，以避免使用暫存檔。

max_binlog_cache_size 系統變數（預設值為 4GB，也是最大值）可用於限制快取多個陳述式交易的總大小。如果交易大於此位元組數，則會失敗並回滾。最小值為 4096。

如果您正在使用二進位日誌和基於列的日誌記錄，則對於 CREATE ... SELECT 或 INSERT ... SELECT 陳述式，並行插入會轉換為常規插入。這樣做是為了確保您可以通過在備份操作期間應用日誌來重新建立表格的精確副本。如果您正在使用基於陳述式的日誌記錄，則原始陳述式會寫入日誌。

二進位日誌格式有一些已知的限制，可能會影響從備份還原。請參閱第 19.5.1 節，「複製功能和問題」。

儲存程式的二進位日誌記錄如第 27.7 節，「儲存程式二進位日誌記錄」中所述。

請注意，由於複製功能的增強，MySQL 8.4 中的二進位日誌格式與以前版本的 MySQL 不同。請參閱第 19.5.2 節，「MySQL 版本之間的複製相容性」。

如果伺服器無法寫入二進位日誌、刷新二進位日誌檔案或將二進位日誌同步到磁碟，則複製來源伺服器上的二進位日誌可能會變得不一致，且副本可能會失去與來源的同步。binlog_error_action 系統變數控制如果遇到此類型的二進位日誌錯誤時所採取的動作。

預設情況下，二進位日誌會在每次寫入時同步到磁碟 (sync_binlog=1)。如果未啟用 sync_binlog，並且作業系統或機器（不僅是 MySQL 伺服器）當機，則二進位日誌的最後陳述式可能會遺失。為防止這種情況，請啟用 sync_binlog 系統變數，以便在每個 N 個提交群組之後將二進位日誌同步到磁碟。請參閱第 7.1.8 節，「伺服器系統變數」。sync_binlog 的最安全值為 1（預設值），但這也是最慢的。

在較早的 MySQL 版本中，即使將 sync_binlog 設定為 1，如果發生當機，表格內容和二進位日誌內容之間仍可能存在不一致的情況。例如，如果您正在使用 InnoDB 表格，並且 MySQL 伺服器處理 COMMIT 陳述式，它會按順序將許多準備好的交易寫入二進位日誌，同步二進位日誌，然後將交易提交到 InnoDB。如果伺服器在這兩個操作之間意外退出，則該交易會在重新啟動時被 InnoDB 回滾，但仍然存在於二進位日誌中。在先前的版本中，通過啟用 XA 交易中對兩階段提交的 InnoDB 支援來解決了此問題。在 MySQL 8.4 中，XA 交易中對兩階段提交的 InnoDB 支援始終啟用。

XA 交易中對兩階段提交的 InnoDB 支援可確保二進位日誌和 InnoDB 資料檔案同步。但是，還應將 MySQL 伺服器配置為在提交交易之前將二進位日誌和 InnoDB 日誌同步到磁碟。預設會同步 InnoDB 日誌，而 sync_binlog=1 可確保同步二進位日誌。XA 交易中對兩階段提交的隱式 InnoDB 支援和 sync_binlog=1 的效果是，在當機後重新啟動時，在回滾交易後，MySQL 伺服器會掃描最新的二進位日誌檔案，以收集交易 xid 值並計算二進位日誌檔案中的最後有效位置。然後，MySQL 伺服器會告知 InnoDB 完成任何已成功寫入二進位日誌的準備好的交易，並將二進位日誌截斷至最後有效位置。這可確保二進位日誌反映 InnoDB 表格的確切資料，因此副本會保持與來源的同步，因為它不會收到已回滾的陳述式。

如果 MySQL 伺服器在當機恢復時發現二進位日誌比預期短，則表示它缺少至少一個已成功提交的 InnoDB 交易。如果 sync_binlog=1 並且磁碟/檔案系統在要求時進行實際同步（有些沒有），則不應發生這種情況，因此伺服器會列印錯誤訊息 二進位日誌 file_name 比預期的大小短。在這種情況下，此二進位日誌不正確，應從來源資料的新快照重新啟動複製。

下列系統變數的工作階段值會寫入二進位日誌，並在剖析二進位日誌時由副本使用