XA transaction support is limited to the XA事务支持仅限于InnoDB storage engine.InnoDB存储引擎。
For “external XA,” a MySQL server acts as a Resource Manager and client programs act as Transaction Managers. 对于“外部XA”，MySQL服务器充当资源管理器，客户端程序充当事务管理器。For “Internal XA”, storage engines within a MySQL server act as RMs, and the server itself acts as a TM. 对于“内部XA”，MySQL服务器中的存储引擎充当RMs，服务器本身充当TM。Internal XA support is limited by the capabilities of individual storage engines. 内部XA支持受到单个存储引擎功能的限制。Internal XA is required for handling XA transactions that involve more than one storage engine. 处理涉及多个存储引擎的XA事务需要内部XA。The implementation of internal XA requires that a storage engine support two-phase commit at the table handler level, and currently this is true only for 内部XA的实现要求存储引擎在表处理程序级别支持两阶段提交，目前这仅适用于InnoDB.InnoDB。
For 对于XA START, the JOIN and RESUME clauses are recognized but have no effect.XA START，可以识别JOIN和RESUME子句，但不起作用。
For 对于XA END the SUSPEND [FOR MIGRATE] clause is recognized but has no effect.XA END，可以识别SUSPEND [For MIGRATE]子句，但不起作用。
The requirement that the 对于全局事务中的每个XA事务，bqual part of the xid value be different for each XA transaction within a global transaction is a limitation of the current MySQL XA implementation. xid值的bqual部分必须不同，这是当前MySQL XA实现的一个限制。It is not part of the XA specification.它不是XA规范的一部分。
An XA transaction is written to the binary log in two parts. XA事务分两部分写入二进制日志。When 发出XA PREPARE is issued, the first part of the transaction up to XA PREPARE is written using an initial GTID. XA PREPARE时，使用初始GTID写入事务的第一部分（直到XA PREPARE）。A XA_prepare_log_event is used to identify such transactions in the binary log. XA_prepare_log_event用于在二进制日志中标识此类事务。When 发出XA COMMIT or XA ROLLBACK is issued, a second part of the transaction containing only the XA COMMIT or XA ROLLBACK statement is written using a second GTID. XA COMMIT或XA ROLLBACK时，使用第二个GTID编写仅包含XA COMMIT或XA ROLLBACK语句的事务的第二部分。Note that the initial part of the transaction, identified by 请注意，事务的初始部分（由XA_prepare_log_event, is not necessarily followed by its XA COMMIT or XA ROLLBACK, which can cause interleaved binary logging of any two XA transactions. XA_prepare_log_event标识）后面不一定跟着XA COMMIT或XA ROLLBACK，这可能导致任何两个XA事务的交错二进制日志记录。The two parts of the XA transaction can even appear in different binary log files. XA事务的两个部分甚至可以出现在不同的二进制日志文件中。This means that an XA transaction in 这意味着在发出显式PREPARED state is now persistent until an explicit XA COMMIT or XA ROLLBACK statement is issued, ensuring that XA transactions are compatible with replication.XA COMMIT或XA ROLLBACK语句之前，处于PREPARED状态的XA事务现在是持久的，以确保XA事务与复制兼容。
On a replica, immediately after the XA transaction is prepared, it is detached from the replication applier thread, and can be committed or rolled back by any thread on the replica. 在复制副本上，准备XA事务后，它立即与复制应用程序线程分离，并且可以由复制副本上的任何线程提交或回滚。This means that the same XA transaction can appear in the 这意味着相同的XA事务可以出现在不同线程上具有不同状态的events_transactions_current table with different states on different threads. events_transactions_current表中。The events_transactions_current table displays the current status of the most recent monitored transaction event on the thread, and does not update this status when the thread is idle. events_transactions_current表显示线程上最近受监视的事务事件的当前状态，并且在线程空闲时不更新此状态。So the XA transaction can still be displayed in the 因此，XA事务在被另一个线程处理后，仍然可以以原始applier线程的PREPARED state for the original applier thread, after it has been processed by another thread. PREPARED状态显示。To positively identify XA transactions that are still in the 要确定仍处于PREPARED state and need to be recovered, use the XA RECOVER statement rather than the Performance Schema transaction tables.PREPARED状态且需要恢复的XA事务，请使用XA RECOVER语句，而不是性能模式事务表。
The following restrictions exist for using XA transactions:使用XA事务存在以下限制：
XA transactions are not fully resilient to an unexpected halt with respect to the binary log. XA事务不能完全适应二进制日志的意外停止。If there is an unexpected halt while the server is in the middle of executing an 如果服务器正在执行XA PREPARE, XA COMMIT, XA ROLLBACK, or XA COMMIT ... ONE PHASE statement, the server might not be able to recover to a correct state, leaving the server and the binary log in an inconsistent state. XA PREPARE、XA COMMIT、XA ROLLBACK或XA COMMIT ... ONE PHASE语句的过程中出现意外停机，那么服务器可能无法恢复到正确的状态，从而使服务器和二进制日志处于不一致的状态。In this situation, the binary log might either contain extra XA transactions that are not applied, or miss XA transactions that are applied. 在这种情况下，二进制日志可能包含未应用的额外XA事务，或者未应用的XA事务。Also, if GTIDs are enabled, after recovery 此外，如果启用了GTID，则在恢复@@GLOBAL.GTID_EXECUTED might not correctly describe the transactions that have been applied. @@GLOBAL.GTID_EXECUTED后，可能无法正确描述已应用的事务。Note that if an unexpected halt occurs before 请注意，如果在XA PREPARE, between XA PREPARE and XA COMMIT (or XA ROLLBACK), or after XA COMMIT (or XA ROLLBACK), the server and binary log are correctly recovered and taken to a consistent state.XA PREPARE之前、XA PREPARE和XA COMMIT（或XA ROLLBACK）之间或XA COMMIT（或XA ROLLBACK）之后发生意外暂停，则服务器和二进制日志将正确恢复并进入一致状态。
The use of replication filters or binary log filters in combination with XA transactions is not supported. 不支持将复制筛选器或二进制日志筛选器与XA事务结合使用。Filtering of tables could cause an XA transaction to be empty on a replica, and empty XA transactions are not supported. 筛选表可能会导致副本上的XA事务为空，并且不支持空XA事务。Also, with the replica's connection metadata repository and applier metadata repository stored in 此外，由于复制副本的连接元数据存储库和applier元数据存储库存储在InnoDB tables, which became the default in MySQL 8.0, the internal state of the data engine transaction is changed following a filtered XA transaction, and can become inconsistent with the replication transaction context state.InnoDB表中（这在MySQL 8.0中成为默认值），数据引擎事务的内部状态在经过过滤的XA事务之后发生更改，并且可能与复制事务上下文状态不一致。
The error 每当XA事务受到复制筛选器的影响时，无论该事务是否因此为空，都会记录错误ER_XA_REPLICATION_FILTERS is logged whenever an XA transaction is impacted by a replication filter, whether or not the transaction was empty as a result. ER_XA_REPLICATION_FILTERS。If the transaction is not empty, the replica is able to continue running, but you should take steps to discontinue the use of replication filters with XA transactions in order to avoid potential issues. 如果事务不是空的，则复制副本可以继续运行，但您应该采取步骤停止对XA事务使用复制筛选器，以避免潜在问题。If the transaction is empty, the replica stops. 如果事务为空，则复制副本停止。In that event, the replica might be in an undetermined state in which the consistency of the replication process might be compromised. 在这种情况下，复制副本可能处于未确定状态，复制过程的一致性可能会受到影响。In particular, the 特别是，副本副本上的gtid_executed set on a replica of the replica might be inconsistent with that on the source. gtid_execute集可能与源副本上的gtid_execute集不一致。To resolve this situation, isolate the source and stop all replication, then check GTID consistency across the replication topology. 要解决此问题，请隔离源并停止所有复制，然后检查整个复制拓扑的GTID一致性。Undo the XA transaction that generated the error message, then restart replication.撤消生成错误消息的XA事务，然后重新启动复制。
XA transactions are considered unsafe for statement-based replication. XA事务对于基于语句的复制被认为是不安全的。If two XA transactions committed in parallel on the source are being prepared on the replica in the inverse order, locking dependencies can occur that cannot be safely resolved, and it is possible for replication to fail with deadlock on the replica. 如果在源上并行提交的两个XA事务正以相反的顺序在副本上准备，则可能会发生无法安全解决的锁定依赖项，并且复制可能会因副本上的死锁而失败。This situation can occur for a single-threaded or multithreaded replica. 对于单线程或多线程复制副本，可能会出现这种情况。When 当设置binlog_format=STATEMENT is set, a warning is issued for DML statements inside XA transactions. binlog_format=STATEMENT时，XA事务中的DML语句将发出警告。When 当设置binlog_format=MIXED or binlog_format=ROW is set, DML statements inside XA transactions are logged using row-based replication, and the potential issue is not present.binlog_format=MIXED或binlog_format=ROW时，XA事务中的DML语句将使用基于行的复制进行记录，并且不存在潜在问题。
Prior to MySQL 5.7.7, XA transactions were not compatible with replication at all. 在MySQL 5.7.7之前，XA事务与复制完全不兼容。This was because an XA transaction that was in 这是因为处于PREPARED state would be rolled back on clean server shutdown or client disconnect. PREPARED状态的XA事务将在干净的服务器关闭或客户端断开连接时回滚。Similarly, an XA transaction that was in 类似地，如果服务器异常关闭然后再次启动，处于PREPARED state would still exist in PREPARED state in case the server was shutdown abnormally and then started again, but the contents of the transaction could not be written to the binary log. PREPARED状态的XA事务仍将处于PREPARED状态，但事务的内容无法写入二进制日志。In both of these situations the XA transaction could not be replicated correctly.在这两种情况下，无法正确复制XA事务。