xa 全局锁_XA事务的隔离级别算什么级别？

同意上面的观点： serializable 隔离级别下， XA 事务是能够避免脏读的。

仔细想一下就能明白：XA 事务由于不同节点 commit 的先后顺序，导致有些节点上的已提交数据在 XA 事务 “真正” 完成 commit 前会被其他事务读到。 但是，XA 只要保证这些这些 “提前读到数据” 的事务，在访问其他节点时，也读到相同的已提交数据就 OK。

换句话说，就是 XA 事务修改了节点 A 上的数据 a --> a', 节点 B 上的数据 b --> b'，在提交阶段，可能 a' 被其他事务读到，这时候只要保证读到 a' 的事务也同时读到 b' ，就是一致的。反过来，如果其他事务读到的是 a', b 或者 a, b', 就违反了一致性，产生了脏读。

想通了这点，就能明白 mysql 为什么要求 XA 事务跑在 serializable 隔离级别了：因为 serializable 级别下 mysql 会对所有 读加锁。还是上面的例子，如果 XA 事务中在节点 A commit 之后，有事务读到了 a'，那么这个事务在读节点 B 时一定会阻塞，不可能读到数据 b。

反之，如果有事务提前读到了 a, 那么其他事务一定会在写入 a --> a' 时阻塞，保证当前事务只会读到 b。不会出现中间事务修改了 a --> a', b --> b' 再 commit，结果让当前事务读到 b' 的情况。

至于有中间事务执行了 b --> b'', 让当前事务读到 a, b'' 的情况 —— 由于中间事务从来没有访问过 a, 从 serializable 的角度我们完全可以认为这个中间事务发生于当前事务之前嘛，不违反一致性。

至于问题 2，分布式事务有没有办法实现 Repeatable-Read 以上的隔离级别，结论当然是可以，而且不需要依赖 XA 这种粗糙的加锁方式。工作相关，就不在这里回答了。