详解数据库中的事务、隔离级别、并发控制

一、什么是事务（Transaction）

　　事务就是一组原子性的SQL查询，或者说一个独立的工作单元。下面我们通过一个银行用户之间的转账这个经典的例子来理解事务。
假设一个银行的数据库中有两张表：支票（checking）表和储蓄表。现在要从用户Jane的支票账户转移200美元到他的储蓄账户，那么至少需要三个步骤：
1、检查支票账户的余额是否大于200美元
2、从支票账户余额中减去200美元
3、在储蓄账户中增加200美元。
将上述的三个步骤的操作必须打包在一个事务中，任何一个步骤失败，则必须回滚所有的步骤。事务SQL的样本如下：

1 START TRANSACTION;
2 SELECT balance FROM checking WHERE customer_id = 10233276;
3 UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 10233276;
4 UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276;
5 COMMIT;

　　但是，单纯事务概念是不能保证操作的正确性的。试想一下如果程序执行到第四条语句时服务器就崩溃了，会发生什么呢？用户可能会损失200美元。所以在事务中还必须要遵循ACID，才能确保事务操作的正确性。那么什么是ACID呢？

原子性(Atomicity)：事务中的全部操作在数据库中是不可分割的，要么全部完成，要么均不执行。这个例子的原子性体现在要么完全提交（10233276的checking余额减少200，savings 的余额增加200），要么完全回滚（两个表的余额都不发生变化）

一致性(Consistency)： 数据库总是从一个一致性状态转换到另一个一致性状态。这个例子的一致性体现在 200元不会因为数据库系统运行到第3行之后，第4行之前时崩溃而不翼而飞，因为事物还没有提交。

隔离性(Isolation)：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务必须是透明的。比如事务A运行到第3行之后，第4行之前，此时事务B去查询checking余额时，它仍然能够看到在事务A中被减去的200元，因为事务A和B是彼此隔离的。在事务A提交之前，事务B观察不到数据的改变。

持久性(Durability)：对于任意已提交事务，系统必须保证该事务对数据库的改变不被丢失，即使数据库出现故障。
　　

二、隔离级别有那些

　　SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。
　　
Read Uncommitted（未提交读）： 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（提交读）：这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一查询可能返回不同结果。

Repeatable Read（可重复读）：这是MySQL的默认事务隔离级别，它确保在一个事务内的相同查询条件的多次查询会看到同样的数据行，都是事务开始时的数据快照。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read），怎么理解幻读？简单说，就是当某个事务在读取某个范围内的记录时， 另外的一个事务又在该范围内插入新的记录。在之前的事务在读取该范围的记录时，就会产生幻行。（InnoDB 通过间隙锁（next-key locking）策略防止幻读的出现）

Serializable（可串行化）：这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

离级别	脏读（Dirty Read）	不可重复读（NonRepeatable Read）	幻读（Phantom Read）
未提交读（Read uncommitted）	可能	可能	可能
提交读（Read committed）	不可能	可能	可能
可重复读（Repeatable read）	不可能	不可能	可能
可串行化（Serializable ）	不可能	不可能	不可能

三、为什么需要并发控制

　　当多个用户(多事务)同时访问和修改数据的时候，如何能保证用户读取数据的一致性? 我们常常用到一种机制称为：并发控制(Concurrency Control)
　　
　　在大多数据库中，锁(Lock) 是并发控制的核心机制之一，锁管理着数据库资源的并发访问，并且防止多用户(多事务) 之间“相互干涉”。下面我们总结一下数据库中常用的锁：
　　
从对数据操作的类型（读\写）来看分为：

　　读锁（共享锁）：针对同一块数据，多个读操作可以同时进行而不会互相影响。

　　写锁（排他锁）：当当前写操作没有完成前，它会阻断其他写锁和读锁。
从锁定的数据范围（锁粒度（Lock granularity））来看分为：

　　表锁：管理锁的开销最小，同时允许的并发量也最小的锁机制。MyIsam存储引擎使用的锁机制。当要写入数据时，把整个表都锁上，此时其他读、写动作一律等待。在MySql中，除了MyIsam存储引擎使用这种锁策略外，MySql本身也使用表锁来执行某些特定动作，比如ALTER TABLE.

　　行锁：可以支持最大并发的锁策略。InnoDB和Falcon两张存储引擎都采用这种策略。