MySQL XA事务
事务是数据库区别于文件系统的重要特性之一。事务会把数据库从一种一致性状态转换为另外一种一致性状态，在数据库提交时，要么确认所有修改都已经保存了，要么所有修改都不保存。InnoDB存储引擎完全满足ACID特性。其中隔离性通过锁实现，事务的原子性和持久性通过redo log实现，undo用来保证事务的一致性。
场景思考
我们在学习数据库事务时经常看到这样的一个经典案例，银行取钱。例如一个用户在ATM机取款，假设取款流程为
（1）、登录ATM机，输入密码并验证
（2）、用户输入取款金额
（3）、银行的数据更新余额信息
（4）、ATM机出钱
整个取款流程视为一个事务，要么全做，要么全不做。及满足ACID特性。这个场景是事务的经典场景，也就是我们最常用的扁平事务。
我们再来看另一个场景，跨行转账。假如一个用户分别拥有建行和招行的两个账户，先将建行账户中的金额转账到招商银行。且建行后台数据库为MySQL，但是招行的后台数据库为oracle，整个转账流程如下：
（1）、登录建行账户，输入密码并验证
（2）、输入转账金额
（3）、更新建行的余额信息
（4）、更新招行余额信息
以上整个流程仍然作为一个事务来处理，操作要么全提交或者全部回滚。不允许出现建行扣了钱，招行没有收到。但是建行和招行使用的不是同一个数据库，如何保证事务的ACID特性。这时候就需要分布式事务，即XA事务。
XA事务
InnoDB存储引擎提供了对XA事务的支持，分布式事务允许多个独立的事务资源参与到一个全局事务中。事务资源通常是关系型数据库系统，使用分布式事务，InnoDB存储引擎的隔离级别必须设置为SERIALIZABLE。XA事务由一个或多个资源管理器（Resource Manager）RM、一个事务管理器（Transaction Manager）TM、以及一个应用程序（Application Program）AP组成。
资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器
事务管理器：协调参与全局事务中的各个事务，需要和参与全局事务的所有资管管理器进行通信
应用程序： 定义事务的边界，指定全局事务中的操作
在MySQL数据库的分布式事务中，资源管理器就是MySQL数据库。事务管理器为连接MySQL服务器的客户端。
两阶段提交
分布式事务采用两阶段提交（two-phare commit）。在第一阶段，所有参与全局事务的节点开始准备（PREPARE），告诉事务管理器他们准备好提交了。在第二阶段，事务管理器告诉资源管理器执行rollback还是commit。如过任何一个节点显示不能提交，则所有的节点都需要回滚。MySQL数据库XA事务的SQL语法如下：
Syntax: XA {START|BEGIN} xid [JOIN|RESUME] XA END xid [SUSPEND [FOR MIGRATE]] XA PREPARE xid XA COMMIT xid [ONE PHASE] XA ROLLBACK xid XA RECOVER [CONVERT XID]
在单个节点运行分布式事务没有太大的意义，但是在MySQL数据库的命令行下演示多个节点参与的分布式事务也是行不通的。通常都是通过编程语言来完成分布式事务的操作。
内部XA事务
MySQL的XA事务支持包括内部XA事务和外部XA事务，内部XA事务主要指单节点实例内部。最常见的内部XA事务存在于binlog和InnoDB存储引擎之间。由于主从复制的需要，生产环境一般都要求开启binlog。在事务提交时，先写binlog，在写InnoDB引擎的重做日志。这两个操作也是原子性的，即binlog和redo必须同时写入，若先写了binlog，在写入redo日志时发生了宕机，那么从节点会收到主节点的binlog并执行重演，导致了主从数据不一致。为了解决上述问题，MySQL数据库内部采用XA事务。