MySQL中的XA事务
存储引擎的事务特性能够保证在存储引擎级别实现ACID，而分布式事务则让存储引擎级别的ACID可以扩展到数据库层面，甚至可以扩展到多个数据库之间-这需要两阶段提交实现。MySQL5.0和更新的版本的数据库已经开始支持XA事务了。
XA事务中需要有一个事务协调器来保证所有的事务参与者都完成了准备工作（第一阶段）。如果协调器受到所有参与者都准备好的消息，就会告诉所有的事务可以提交了，这时第二阶段。MySQL在这个XA事务过程中扮演一个参与者的角色，而不是协调者。
实际上，在MySQL中有两种XA事务。一方面，MySQL可以参与到外部的分布式事务中；另一方面，还可以通过XA事务来协调存储引擎和二进制日志。
内部XA事务
MySQL本身的插件式架构导致再起内部需要使用XA事务。MySQL中各个存储引擎是完全独立的，彼此不知道对方的存在，所以一个跨存储引擎的事务就需要一个外部的协调者。如果不使用XA协议，例如，跨存储引擎的事务提交就只是顺序地要求每个存储引擎各自提交。如果在某个存储提交过程中发生系统崩溃，就会破坏事务的特性。（要么全部提交，要么不做任何操作）。
如果将MySQL记录的二进制日志操作看做一个独立的“存储引擎”，就不难理解为什么即使是一个存储殷勤参数的事务仍然需要XA事务了。在存储引擎提交的同时，需要将“提交”的信息写入二进制日志，这是一个分布式事务，只不过二进制日志的参与者是MySQL本身。
外部XA事务
外部XA用于跨多MySQL实例的分布式事务，需要应用层作为协调者，通俗的说就是比如我们在PHP中写代码，那么PHP书写的逻辑就是协调者。应用层负责决定提交还是回滚，崩溃时的悬挂事务。MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持。
MySQL事务基本语法
XA {START|BEGIN} xid [JOIN|RESUME] 启动xid事务 (xid 必须是一个唯一值; 不支持[JOIN|RESUME]子句)
XA END xid [SUSPEND [FOR MIGRATE]] 结束xid事务 ( 不支持[SUSPEND [FOR MIGRATE]] 子句)
XA PREPARE xid 准备、预提交xid事务
XA COMMIT xid [ONE PHASE] 提交xid事务
XA ROLLBACK xid 回滚xid事务
XA RECOVER 查看处于PREPARE 阶段的所有事务