MySQL 8.4 發行說明
在同一交易中混合使用交易性和非交易性陳述式。 一般來說，您應避免在複製環境中同時更新交易性和非交易性資料表的交易。您也應避免使用任何會存取交易性（或暫時性）和非交易性資料表，並寫入其中任何資料表的陳述式。
伺服器會使用這些規則進行二進位記錄
如果交易中的初始陳述式是非交易性的，則會立即寫入二進位日誌。交易中的剩餘陳述式會被快取，並且直到交易被提交後才會寫入二進位日誌。（如果交易回滾，快取的陳述式只有在進行無法回滾的非交易性變更時才會寫入二進位日誌。否則，它們會被捨棄。）
對於基於語句的日誌記錄，非事務性語句的日誌記錄會受到
binlog_direct_non_transactional_updates系統變數的影響。當此變數為OFF（預設值）時，日誌記錄如剛才所述。當此變數為ON時，對於事務中任何地方發生的非事務性語句（而不僅僅是初始非事務性語句），會立即進行日誌記錄。其他語句會保留在事務快取中，並在事務提交時記錄。binlog_direct_non_transactional_updates對於以列格式或混合格式的二進位日誌記錄沒有影響。
事務性、非事務性和混合語句。 為了應用這些規則，如果一個語句僅變更非事務性表格，伺服器會將其視為非事務性語句；如果它僅變更事務性表格，則視為事務性語句。一個同時參考非事務性和事務性表格，並且更新任何所涉及的表格的語句，會被視為「混合」語句。混合語句與事務性語句一樣，會被快取並在事務提交時記錄。
如果混合語句同時執行以下任一動作，則該更新事務性表格的混合語句會被視為不安全：
更新或讀取暫存表格
讀取非事務性表格，且事務隔離等級低於 REPEATABLE_READ
如果在事務中更新事務性表格之後，混合語句執行以下任一動作，則會被視為不安全：
更新任何表格並從任何暫存表格讀取資料
更新非事務性表格且
binlog_direct_non_transactional_updates為 OFF
如需更多資訊，請參閱章節 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）的表格的語句也是如此。
注意
如需特別適用於 XA 事務的限制，請參閱章節 15.3.8.3，「XA 事務的限制」。