在同一個交易中混合交易式和非交易式陳述式。 在 MySQL 9.0 (及更高版本) 中，更新交易式表格和非交易式或不可組合表格的交易已棄用，並且會將棄用警告寫入用戶端和錯誤日誌中。在 MySQL 9.0 中，只有 InnoDB 和 BLACKHOLE 儲存引擎是交易式和可組合的；NDBCLUSTER 是交易式的，但不可組合。這表示唯一 不會 引發棄用警告的儲存引擎組合是此處列出的組合

一般而言，您應該避免在複製環境中更新交易式和非交易式表格的交易。您也應該避免使用任何存取交易式 (或暫時) 和非交易式表格，並將寫入它們的陳述式。

伺服器會將這些規則用於二進制日誌記錄

事務性、非事務性及混合陳述式。 為了應用這些規則，伺服器會將僅變更非事務性資料表的陳述式視為非事務性，而將僅變更事務性資料表的陳述式視為事務性。如果陳述式同時參考非事務性和事務性資料表，並更新所涉及的任何資料表，則會被視為「混合」陳述式。混合陳述式與事務性陳述式一樣，會在交易提交時快取並記錄。

如果混合陳述式更新了事務性資料表，且該陳述式同時執行以下任一動作，則會被視為不安全：

如果混合陳述式在交易中更新事務性資料表後，執行以下任一動作，則會被視為不安全：

如需更多資訊，請參閱章節 19.2.1.3「二進位日誌中安全與不安全陳述式的判定」。

在交易混合更新事務性和非事務性資料表的情況下，二進位日誌中的陳述式順序是正確的，即使發生ROLLBACK，所有需要的陳述式都會寫入二進位日誌。但是，當第二個連線在第一個連線的交易完成之前更新非事務性資料表時，陳述式可能會記錄為順序錯誤，因為第二個連線的更新會在執行後立即寫入，而不管第一個連線執行的交易狀態如何。

在來源和複本上使用不同的儲存引擎。 可以在來源上使用事務性資料表，在複本上使用非事務性資料表進行複寫。例如，您可以將 InnoDB 來源資料表複寫為 MyISAM 複本資料表。但是，如果這樣做，如果複本在 BEGIN ... COMMIT 區塊的中間停止，則會出現問題，因為複本會在 BEGIN 區塊的開頭重新啟動。

將交易從來源上的 MyISAM 資料表複寫到複本上的事務性資料表（例如使用 InnoDB 儲存引擎的資料表）也是安全的。在這種情況下，來源上發出的 AUTOCOMMIT=1 陳述式會被複寫，從而在複本上強制執行 AUTOCOMMIT 模式。

當複本的儲存引擎類型為非事務性時，應避免在來源上混合更新事務性和非事務性資料表的交易，因為這可能會導致來源事務性資料表和複本非事務性資料表之間的資料不一致。也就是說，此類交易可能會導致來源儲存引擎特定的行為，並可能導致複寫不同步。MySQL 不會發出有關此問題的警告，因此在將來源的事務性資料表複寫到複本上的非事務性資料表時，應格外小心。

在交易中變更二進位日誌格式。只要交易正在進行，binlog_format 和 binlog_checksum 系統變數都是唯讀的。

每個交易（包括 autocommit 交易）都會在二進位日誌中記錄，就好像它是以 BEGIN 陳述式開始，並以 COMMIT 或 ROLLBACK 陳述式結束。即使對於影響使用非事務性儲存引擎（例如 MyISAM）的資料表的陳述式也是如此。