二進制日誌包含描述資料庫變更的「「事件」」，例如表格建立操作或表格資料的變更。它還包含可能已進行變更的陳述式的事件 (例如，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 (接收器) 執行緒也會驗證從來源接收的事件。您可以讓複寫 SQL (應用程式) 執行緒在從繼電器日誌讀取時使用總和檢查碼 (如果有的話)，方法是啟用 replica_sql_verify_checksum。

二進制日誌中記錄的事件格式取決於二進制日誌記錄格式。支援三種格式類型：以列為基礎的日誌記錄、以陳述式為基礎的日誌記錄和混合型日誌記錄。使用的二進制日誌記錄格式取決於 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.8 節「儲存程式二進制日誌記錄」中所述。

請注意，由於複製功能的增強，MySQL 9.0 中的二進制日誌格式與先前版本的 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 9.0 中，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 比預期大小短。在這種情況下，此二進制日誌不正確，應從來源資料的新快照重新啟動複製。

以下系統變數的工作階段值會寫入二進制日誌，並在副本剖析二進制日誌時受到尊重