MySQL 9.0 發行說明
XA 交易支援僅限於 InnoDB 儲存引擎。
對於「外部 XA」，MySQL 伺服器作為資源管理器 (Resource Manager)，而用戶端程式則作為交易管理器 (Transaction Manager)。對於「內部 XA」，MySQL 伺服器內的儲存引擎則作為資源管理器，而伺服器本身則作為交易管理器。內部 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 語法，而不是效能綱要交易資料表。
使用 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語法仍在執行中，就可能會發生這種情況。這是一個已知問題。