7.6 事务的隔离级别
ISO和ANIS SQL标准制定了四种事务隔离级别的标准，但是很少有数据库厂商遵循这些标准。比如oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ的事务隔离级别。
InnoDB存储引擎默认支持的隔离级别是REPEATABLE READ，但是与标准SQL不同的是，InnoDB存储引擎在REPEATABLE READ事务隔离级别下，使用Next-Key Lock锁的算法，因此避免幻读的产生。这与其他数据库系统是不同的。所以说，InnoDB存储引擎在默认的RR事务隔离级别下已经能完全保证事务隔离性的要求，即达到SQL标准的SERIALIZABLE隔离级别。
7.7 分布式事务
7.7.1 MySQL数据库分布式事务
InnoDB储存引擎提供了对XA事务的支持，并通过XA事务来支持分布式事务的实现。分布式事务指的是允许多个独立的事务资源参与到一个全局的事务中。事务资源通常是关系型数据库系统，但也可以是其他类型的资源。全局事务要求在其中的所有参与的事务要么都提交，要么都回滚，这对于事务原有的ACID要求又有了提高。另外，在使用分布式事务时，InnoDB存储引擎的事务隔离级别必须设置为 SERIALIZABLE
XA事务允许不同数据库之间的分布式事务，如一台服务器是MySQL数据库，另一台是Oracle数据库，只要参与在全局事务中的每个节点都支持XA事务。
XA事务由一个或多个资源管理器，一个事务管理器以及一个应用程序组成。
资源管理器：提供事务访问事务资源的方法。通常一个数据库就是一个资源管理器
事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信
应用程序：定义事务的边界，指定全局事务中的操作
7.7.2 内部XA事务
MySQL数据库中还存在另外一种分布式事务，其在存储引擎与插件之间，又或者在存储引擎与存储引擎之间，称为内部XA事务
最常见的内部XA事务存在于bin log和InnoDB存储引擎之间。由于复制的需要，因此目前大多数的数据库开启了bin log功能。在事务提交时，先写二进制日志，再写InnoDB存储引擎日志。对上述两个操作的要求也是原子的，即二进制日志和重做日志必须同时写入。若二进制日志先写了，而在写入InnoDB存储引擎时发生了宕机，那么salve可能会接收到master传过去的二进制日志并执行，最终导致了主从不一致的情况。为了解决这个问题，MySQL数据库在bin log与InnoDB存储引擎之间采用了XA事务。当事务提交时，InnoDB存储引擎会先做一个prepare操作，将事务的xid写入，接着进行二进制日志的写入，如果在InnoDB存储引擎提交前，MySQL数据库宕机了，那么MySQL数据库在重启后会先检查准备的UXID事务是否已经提交，若没有，则在存储引擎层再进行一次提交操作。
7.8 不好的事务习惯
- 在循环中提交
- 使用自动提交
- 使用自动回滚
7.9 长事务
长事务就是执行时间比较长的事务。对于长事务，有时可以通过转化为小批量的事务来进行处理，当事务发生错误时，只需要回滚一部分数据，然后接着上次已完成的事务继续进行。
