T2时刻:AB账户均完成xa prepare操作,一个减20,一个加20。当处在RR或RC隔离级别时,发起一个对账操作,统计AB帐户资金总额,当只有他们相互转账时,总金额应该恒为200。T6 时刻时,查询A为80,B为120,总账为200,无问题。T4时刻查询A账户为80,查询B账户时由于MVCC机制,会读到上个快照中的值100,加一起为180,总账不对。因为是操作不同实例,当开始做xa commit之后,可能由于网络等原因,并不能保证所有节点的XA commit同时到达所有节点,在一个高并发场景,导致上面的问题几乎是必然的。因此,当使用MySQL 原生XA分布式事务时,若无其它手段来保障读一致性,而应用又有跨节点读的应用场景,应当使用序列化(SERIALIZABLE)隔离级别,“may not be sufficien”显然是不恰当的,没有任何一个业务能接受这种数据统计不对的。如果是序列化隔离级别,T4时刻读到A为80,读B时会等待,直到T5时刻XA commit成功之后, 才能读到B为120,总账200,无问题。序列化隔离级别只有读-读不阻塞,读-写,写-读,写-写均会阻塞,而RC、RR仅写-写阻塞,因此只有序列化隔离级才能充分保障MySQL XA事务的读一致性。但它阻塞太多,性能也是各种隔离级别中最差的,所以如无必要,通常不会使用这一隔离级别。业界有很多方案来解决分布式事务RR、RC下的读一致性问题,以提高数据库性能,但原生的MySQL不具备这种能力,因此使用MySQL原生XA事务的业务需要谨慎选择隔离级别。只要我们小心面对残留XA事务,谨慎处理Crash之后的可能存在的多余binlog数据,认真评估使用RR、RC隔离级别是否有读一致性读问题等问题之后,MySQL 的XA事务基本没有其它问题,可以作为RM完备提供跨节点分布式事务能力,MySQL已经实现了X/Open 组织定义的分布式事务处理规范中的语法功能,完全可以放心放业务在这条路上奔跑!