MySQL 8.4 發行說明
XA 交易支援僅限於 InnoDB 儲存引擎。
對於「外部 XA」，MySQL 伺服器充當資源管理器，而用戶端程式充當交易管理器。對於「內部 XA」，MySQL 伺服器內的儲存引擎充當 RM，而伺服器本身充當 TM。內部 XA 支援受到個別儲存引擎功能的限制。處理涉及多個儲存引擎的 XA 交易時，需要內部 XA。內部 XA 的實作要求儲存引擎在資料表處理常式層級支援兩階段提交，而目前僅有 InnoDB 符合此條件。
對於 XA START，會辨識 JOIN 和 RESUME 子句，但它們沒有任何作用。
對於 XA END，會辨識 SUSPEND [FOR MIGRATE] 子句，但它沒有任何作用。
在全域交易中，每個 XA 交易的 xid 值的 bqual 部分必須不同，這是目前 MySQL XA 實作的限制。它並非 XA 規格的一部分。
XA 交易會分兩部分寫入二進位日誌。當發出 XA PREPARE 時，交易的第一部分（直到 XA PREPARE）會使用初始 GTID 寫入。XA_prepare_log_event 用於識別二進位日誌中的這類交易。當發出 XA COMMIT 或 XA ROLLBACK 時，交易的第二部分（僅包含 XA COMMIT 或 XA ROLLBACK 陳述式）會使用第二個 GTID 寫入。請注意，交易的初始部分（由 XA_prepare_log_event 識別）不一定會接著它的 XA COMMIT 或 XA ROLLBACK，這可能會導致任何兩個 XA 交易的二進位日誌交錯。XA 交易的兩個部分甚至可能出現在不同的二進位日誌檔中。這表示 PREPARED 狀態的 XA 交易現在會持續存在，直到發出明確的 XA COMMIT 或 XA ROLLBACK 陳述式，從而確保 XA 交易與複寫相容。
在複本上，在準備 XA 交易後，它會立即與複寫套用程式執行緒分離，並且可以由複本上的任何執行緒提交或復原。這表示相同的 XA 交易可能會在 events_transactions_current 資料表中，在不同的執行緒上具有不同的狀態。events_transactions_current 資料表會顯示執行緒上最近監視的交易事件的目前狀態，並且在執行緒閒置時不會更新此狀態。因此，在由另一個執行緒處理後，XA 交易仍可能在原始套用程式執行緒中顯示為 PREPARED 狀態。若要明確識別仍處於 PREPARED 狀態且需要復原的 XA 交易，請使用 XA RECOVER 陳述式，而不是 Performance Schema 交易資料表。
使用 XA 交易時存在以下限制
不支援將複寫篩選器或二進位日誌篩選器與 XA 交易結合使用。篩選資料表可能會導致複本上的 XA 交易為空，而且不支援空的 XA 交易。此外，由於複本的連線中繼資料儲存庫和套用程式中繼資料儲存庫儲存在
InnoDB資料表（預設）中，因此在篩選過的 XA 交易之後，資料引擎交易的內部狀態會變更，並且可能會與複寫交易內容狀態不一致。無論交易是否因此為空，只要 XA 交易受到複寫篩選器的影響，就會記錄錯誤
ER_XA_REPLICATION_FILTERS。如果交易不為空，複本可以繼續執行，但您應採取步驟停止將複寫篩選器與 XA 交易搭配使用，以避免潛在問題。如果交易為空，複本會停止。在這種情況下，複本可能處於未確定的狀態，其中複寫程序的一致性可能會受到損害。尤其是，複本的複本上的gtid_executed集合可能與來源上的不一致。若要解決此情況，請隔離來源並停止所有複寫，然後檢查整個複寫拓樸的 GTID 一致性。復原產生錯誤訊息的 XA 交易，然後重新啟動複寫。XA 交易被認為對於基於陳述式的複寫是不安全的。如果在來源上並行提交的兩個 XA 交易在複本上以相反的順序準備，則可能會發生無法安全解決的鎖定相依性，並且複寫可能因複本上的死結而失敗。這種情況可能會發生在單執行緒或多執行緒的複本上。當設定
binlog_format=STATEMENT時，會針對 XA 交易內的 DML 陳述式發出警告。當設定binlog_format=MIXED或binlog_format=ROW時，XA 交易內的 DML 陳述式會使用基於資料列的複寫來記錄，而且不會出現潛在的問題。您應該知道，當使用相同的交易 XID 循序執行 XA 交易，並且在處理
XA COMMIT ... ONE PHASE期間發生中斷時，可能無法再同步二進位日誌與儲存引擎之間的狀態。如果上述事件系列在儲存引擎中準備好此交易之後，在XA COMMIT陳述式仍在執行時發生，就可能發生這種情況。這是已知問題。