文件首頁
MySQL 8.4 參考手冊
相關文件 下載本手冊
PDF (美式信紙) - 39.9Mb
PDF (A4) - 40.0Mb
Man Pages (TGZ) - 258.5Kb
Man Pages (Zip) - 365.5Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 8.4 參考手冊  /  ...  /  設定二進位日誌格式

7.4.4.2 設定二進位日誌格式

您可以透過使用 --binlog-format=type 啟動 MySQL 伺服器,來明確選擇二進位日誌格式。 type 的支援值為:

  • STATEMENT 會導致日誌記錄以陳述式為基礎。

  • ROW 會導致日誌記錄以列為基礎。這是預設值。

  • MIXED 會導致日誌記錄使用混合格式。

設定二進位日誌格式不會啟動伺服器的二進位日誌記錄。只有在伺服器上啟用二進位日誌記錄時,設定才會生效,這是在 log_bin 系統變數設定為 ON 時的情況。在 MySQL 8.4 中,二進位日誌記錄預設為啟用,僅當您使用 --skip-log-bin--disable-log-bin 啟動伺服器時才會停用。

日誌格式也可以在執行時切換,但請注意,在某些情況下您無法這樣做,本節稍後將討論。設定 binlog_format 系統變數的全域值,以指定變更後連線的用戶端的格式。

mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';

個別用戶端可以透過設定 binlog_format 的工作階段值,來控制其自身陳述式的日誌格式。

mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';

變更全域 binlog_format 值需要足夠的權限來設定全域系統變數。變更工作階段 binlog_format 值需要足夠的權限來設定受限制的工作階段系統變數。請參閱第 7.1.9.1 節,「系統變數權限」

用戶端可能想要針對每個工作階段設定二進位日誌記錄,有以下幾個原因:

  • 對資料庫進行許多小型變更的工作階段可能想要使用以列為基礎的日誌記錄。

  • 執行與 WHERE 子句中多列符合的更新的工作階段可能想要使用以陳述式為基礎的日誌記錄,因為記錄少數陳述式比記錄許多列更有效率。

  • 某些陳述式在來源上需要大量執行時間,但只會導致修改少數列。因此,使用以列為基礎的日誌記錄複寫它們可能是有益的。

在某些情況下,您無法在執行時切換複寫格式:

  • 複寫格式無法從儲存函式或觸發器內變更。

  • 如果啟用 NDB 儲存引擎。

  • 如果連線階段有開啟的暫存表格,則無法變更該連線階段的複製格式 (SET @@SESSION.binlog_format)。

  • 如果任何複製通道有開啟的暫存表格,則無法全域變更複製格式 (SET @@GLOBAL.binlog_formatSET @@PERSIST.binlog_format)。

  • 如果任何複製通道應用程式執行緒目前正在執行,則無法全域變更複製格式 (SET @@GLOBAL.binlog_formatSET @@PERSIST.binlog_format)。

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

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

在複製正在進行時切換複製格式也可能導致問題。每個 MySQL 伺服器都可以設定自己的二進位記錄格式 (無論 binlog_format 是設定為全域或連線階段範圍)。這表示在複製來源伺服器上變更記錄格式不會導致副本變更其記錄格式以符合。當使用 STATEMENT 模式時,binlog_format 系統變數不會被複製。當使用 MIXEDROW 記錄模式時,它會被複製,但會被副本忽略。

副本無法將以 ROW 記錄格式接收到的二進位日誌條目轉換為 STATEMENT 格式,以供其自身的二進位日誌使用。因此,如果來源使用 ROW 格式,則副本必須使用 ROWMIXED 格式。在複製正在進行時,將來源上的二進位記錄格式從 STATEMENT 變更為 ROWMIXED,而副本的格式為 STATEMENT,可能會導致複製失敗,並出現錯誤,例如 執行列事件時發生錯誤:'無法執行語句:由於語句為列格式且 BINLOG_FORMAT = STATEMENT,因此無法寫入二進位日誌。' 如果來源仍然使用 MIXEDROW 格式,則將副本上的二進位記錄格式變更為 STATEMENT 格式也會導致相同類型的複製失敗。若要安全地變更格式,您必須停止複製,並確保在來源和副本上都進行相同的變更。

如果您使用的是 InnoDB 表格,且交易隔離層級為 READ COMMITTEDREAD UNCOMMITTED,則只能使用基於列的記錄。將記錄格式變更為 STATEMENT有可能的,但這樣做會在執行時很快導致錯誤,因為 InnoDB 無法再執行插入。

當二進位日誌格式設定為 ROW 時,許多變更會使用基於列的格式寫入二進位日誌。但是,某些變更仍然使用基於語句的格式。例如,所有 DDL (資料定義語言) 語句,例如 CREATE TABLEALTER TABLEDROP TABLE

當使用基於列的二進位日誌時,binlog_row_event_max_size 系統變數及其對應的啟動選項 --binlog-row-event-max-size 會設定列事件的最大大小的軟限制。預設值為 8192 位元組,並且該值只能在伺服器啟動時變更。在可能的情況下,儲存在二進位日誌中的列會分組為大小不超過此設定值的事件。如果事件無法分割,則可能會超過最大大小。

--binlog-row-event-max-size 選項適用於能夠進行基於列的複製的伺服器。列會以位元組為單位儲存在二進位日誌中,其大小不超過此選項的值。該值必須是 256 的倍數。預設值為 8192。

警告

當使用基於語句的記錄進行複製時,如果語句的設計方式使得資料修改是非決定性的,也就是說,它取決於查詢最佳化程式,則來源和副本上的資料可能會變得不同。一般來說,即使在複製之外,這也不是一個好做法。有關此問題的詳細說明,請參閱第 B.3.7 節「MySQL 中的已知問題」