MySQL 事务的四个隔离级别
原子性（ atomicity ) 一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是辜务的原子性。
一致性（ consistency ) 数据库总是从一个一致性的状态转换到另外一个一致性的状态。
在前面的例子中，一致性确保了，即使在执行第三、四条语句之间时系统崩溃，支票账户中也不会损失 200 美元，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中。
隔离性（ isolation ) 通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。
在前面的例子中，当执行完第三条语句、第四条语句还未开始时，此时有另外一个账户汇总程序开始运行，则其看到的支票账户的余额并没有被减去 200 美元。
后面我们讨论隔离级别（ Isolation level ）的时候，会发现为什么我们要说“通常来说”是不可见的。
持久性（ durability ) 一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。
持久性是个有点模糊的概念，因为实际上持久性也分很多不同的级别。有些持久性策略能够提供非常强的安全保障，而有些则未必。
而且不可能有能做到 100 ％的持久性保证的策略（如果数据库本身就能做到真正的持久性，那么备份又怎么能增加持久性呢？）。
在后面的一些章节中，我们会继续讨论 MySQL 中持久性的真正含义。事务的 ACID 特性可以确保银行不会弄丢你的钱。而在应用逻辑中，要实现这一点非常难，甚至可以说是不可能完成的任务。
一个兼容 ACID 的数据库系统，需要做很多复杂但可能用户并没有觉察到的工作，才能确保 ACID 的实现。
就像锁粒度的升级会增加系统开销一样，这种事务处理过程中额外的安全性，也会需要数据库系统做更多的额外工作。
一个实现了 ACID 的数据库，相比没有实现 ACID 的数据库，通常会需要更强的 CPU 处理能力、更大的内存和更多的磁盘空间。
正如本章不断重复的，这也正是 MysQL 的存储引攀架构可以发挥优势的地方。用户可以根据业务是否需要事务处理，来选择合适的存储引笨。
对于一些不需要事务的查询类应用，选择一个非事务型的存储引攀，可以获得更高的性能。即使存储引攀不支持事务，也可以通过 LOCK TABLES 语句为应用提供一定程度的保护，这些选择用户都可以自主决定。
下面简单地介绍一下四种隔离级别。
READ UNCOMMITTED （未提交读）
在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（ Dirty Read ）。
这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，
但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。
READ COMMITTED（提交读）
大多数数据库系统的默认隔离级别都是 READ COMMITTED（但 MysQL 不是）。
READ COMMITTED 满足前面提到的隔离性的简单定义：一个事务开始时，只能“看见”已经提交的事务所做的修改。
换句话说，
一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。
这个级别有时候也叫做不可重复读（nonrepeatable read) ，因为两次执行同样的查询，可能会得到不一样的结果。
REPEATABLE READ（可重复读）
REPEATABLE READ 解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。
但是理论上，可重复读隔离级别还是无法解决另外一个幻读 ( Phantom Read ）的问题。
所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，
当之前的事务再次读取该范围的记录时，会产生幻行（ Phantom Row ）。
InnoDB 和 XtraDB 存储引攀通过多版本并发控制（ Mvcc , Multiversion Concurrency Control ）解决了幻读的问题。
本章稍后会做进一步的讨论。
可重复读是 MySQL 的默认事务隔离级别。
SERIALIZABLE （可串行化）
SERIALIZABLE 是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。
简单来说， SERIALIZABLE 会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。
实际应用中也很少用到这个隔离级别．只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。
