一、事务的四大特性（ACID）
如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性：
1.1 原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
1.2 一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
1.3 隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
1.4 持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。
二、数据库隔离级别
数据库事务的隔离级别有4个。由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable。这四个级别能够逐个解决脏读、不可反复读、幻读这几类问题。MySQL设置的隔离级别默认是Repeatable Read可反复读级别
注意：MySQL 中默认的事务隔离级别就是 Repeatable Read可反复读级别，但是它通过 Next-Key 锁也能够在某种程度上解决幻读的问题。
| 事务级别 | 脏读 | 不可反复读 | 幻读 |
|---|---|---|---|
| Read uncommitted | √ | √ | √ |
| Read committed | × | √ | √ |
| Repeatable read | × | × | √ |
| Serializable | × | × | × |
√: 可能出现 ×: 不会出现
注意：我们讨论隔离级别的场景，主要是在多个事务并发的情况下。因此，接下来的解说都环绕事务并发。
2.1 Read uncommitted 读未提交
Read uncommitted是限制性最弱的隔离级别。由于该级别忽略其它事务放置的锁。使用READ UNCOMMITTED级别运行的事务，能够读取尚未由其它事务提交的改动后的数据值，这些行为称为“脏”读。我们所说的脏读，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。比方，事务1改动一行，事务2在事务1提交之前读取了这一行。假设事务1回滚，事务2就读取了一行没有提交的数据。这种数据我们觉得是不存在的。
补充：
比如事务B读取了事务A 更改但未提交的数据D。有人会问，这会有什么问题吗？如果事务A没有再修改数据D，并且事务也没有出错正常提交了，其实事务B读取了数据D没有什么问题。但如果事务B读取数据D后，事务A又改了数据D呢？甚至如果事务A失败回滚了呢？那么事务B读的数据D就是错的值，如果事务B对这个数据D再做修改，肯定就是错的。
2.2 Read committed 读提交
该级别通过指定语句不能读取其它事务已改动可是尚未提交的数据值。禁止运行脏读。在当前事务中的各个语句运行之间，其它事务仍能够改动、插入或删除数据。从而产生无法反复的读操作。或“影子”数据。比方，事务1读取了一行。事务2改动或者删除这一行而且提交。假设事务1想再一次读取这一行，它将获得改动后的数据或者发现这一样已经被删除。因此事务的第二次读取结果与第一次读取结果不同，因此也叫不可反复读。
大多数数据库的默认级别就是Read committed。比方Sql Server , Oracle。怎样解决不可反复读这一问题。请看下一个隔离级别。
2.3 Repeatable read 反复读
Repeatable read是比Read committed限制性更强的隔离级别。
该级别包含Read committed，而且另外指定了在当前事务提交之前。其它不论什么事务均不能够改动或删除当前事务已读取的数据。并发性低于Read committed。由于已读数据的共享锁在整个事务期间持有，而不是在每一个语句结束时释放。
这个隔离级别仅仅是说，不可以改动和删除，可是并没有强制不能插入新的满足条件查询的数据行。此可以得出结论：Read committed隔离级别保证了在同样的查询条件下，同一个事务中的两个查询。第二次读取的内容肯定包含第一次读到的内容。
反复读与幻读
反复读是为了保证在一个事务中，相同查询条件下读取的数据值不发生改变，可是不能保证下次相同条件查询。结果记录数不会添加。
幻读就是为了解决问题而存在的，他将这个查询范围都加锁了。所以就不能再往这个范围内插入数据。这就是SERIALIZABLE 隔离级别做的事情。
2.4 Serializable 序列化
Serializable 是限制性最强的隔离级别，由于该级别锁定整个范围的键。并一直持有锁，直到事务完毕。该级别包含REPEATABLE READ。并添加了在事务完毕之前，其它事务不能向事务已读取的范围插入新行的限制。比方，事务1读取了一系列满足搜索条件的行。事务2在运行SQL statement产生一行或者多行满足事务1搜索条件的行时会冲突。则事务2回滚。这时事务1再次读取了一系列满足同样搜索条件的行。第二次读取的结果和第一次读取的结果同样。
三、锁
3.1 一次封锁or两段锁？
由于有大量的并发訪问，为了预防死锁。一般应用中推荐使用一次封锁法。就是在方法的開始阶段。已经预先知道会用到哪些数据，然后所有锁住，在方法执行之后，再所有解锁。
这样的方式能够有效的避免循环死锁，但在数据库中却不适用，由于在事务開始阶段，数据库并不知道会用到哪些数据。数据库遵循的是两段锁协议，将事务分成两个阶段，加锁阶段和解锁阶段（所以叫两段锁）
-
加锁阶段：在该阶段能够进行加锁操作。在对不论什么数据进行读操作之前要申请并获得S锁（共享锁，其他事务能够继续加共享锁，但不能加排它锁），在进行写操作之前要申请并获得X锁（排它锁，其他事务不能再获得不论什么锁）。加锁不成功，则事务进入等待状态，直到加锁成功才继续运行。
-
解锁阶段：当事务释放了一个封锁以后，事务进入解锁阶段。在该阶段仅仅能进行解锁操作不能再进行加锁操作。
事务 加锁/解锁处理
begin。
insert into test ..... 加insert相应的锁
update test set... 加update相应的锁
delete from test .... 加delete相应的锁
commit; 事务提交时，同一时候释放insert、update、delete相应的锁
这样的方式尽管无法避免死锁。可是两段锁协议能够保证事务的并发调度是串行化（串行化非常重要，尤其是在数据恢复和备份的时候）的。
3.2不可反复读和幻读的差别
非常多人easy搞混不可反复读和幻读，确实这两者有些相似。但不可反复读重点在于update和delete。而幻读的重点在于insert。
假设使用锁机制来实现这两种隔离级别。在可反复读中，该sql第一次读取到数据后。就将这些数据加锁，其他事务无法改动这些数据。就能够实现可反复读了。但这样的方法却无法锁住insert的数据。所以当事务A先前读取了数据，或者改动了所有数据，事务B还是能够insert数据提交，这时事务A就会发现莫名其妙多了一条之前没有的数据。这就是幻读。不能通过行锁来避免。须要Serializable隔离级别 。读用读锁，写用写锁，读锁和写锁相互排斥，这么做能够有效的避免幻读、不可反复读、脏读等问题，但会极大的减少数据库的并发能力。
所以说不可反复读和幻读最大的差别，就在于怎样通过锁机制来解决他们产生的问题。
上文说的，是使用悲观锁机制来处理这两种问题，可是MySQL、ORACLE、PostgreSQL等成熟的数据库。出于性能考虑，都是使用了以乐观锁为理论基础的MVCC（多版本号并发控制）来避免这两种问题。
3.3 悲观锁和乐观锁
悲观锁
正如其名，它指的是对数据被外界（包含本系统当前的其它事务，以及来自外部系统的事务处理）改动持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现。往往依靠数据库提供的锁机制（也仅仅有数据库层提供的锁机制才干真正保证数据訪问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会改动数据）。在悲观锁的情况下，为了保证事务的隔离性，就须要一致性锁定读。读取数据时给加锁，其他事务无法改动这些数据。改动删除数据时也要加锁，其他事务无法读取这些数据。
乐观锁
相对悲观锁而言，乐观锁机制採取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销。特别是对长事务而言，这种开销往往无法承受。而乐观锁机制在一定程度上攻克了这个问题。乐观锁，大多是基于数据版本号（ Version ）记录机制实现。何谓数据版本号？即为数据添加一个版本号标识，在基于数据库表的版本号解决方式中，通常是通过为数据库表添加一个“version” 字段来实现。读取出数据时，将此版本号号一同读出，之后更新时，对此版本号号加一。
此时。将提交数据的版本号数据与数据库表相应记录的当前版本号信息进行比对，假设提交的数据版本号号大于数据库表当前版本号号，则予以更新。否则觉得是过期数据。
要说明的是，MVCC的实现没有固定的规范，每一个数据库都会有不同的实现方式，这里讨论的是InnoDB的MVCC。
四、MVCC在MySQL的InnoDB中的实现
在InnoDB中，会在每行数据后加入两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中。存储的并非时间，而是事务的版本，每开启一个新事务，事务的版本就会递增。 在可重读Repeatable reads事务隔离级别下：
SELECT时。读取创建版本<=当前事务版本。删除版本为空或>当前事务版本。
INSERT时，保存当前事务版本为行的创建版本
DELETE时，保存当前事务版本为行的删除版本
UPDATE时，插入一条新纪录。保存当前事务版本为行创建版本，同一时候保存当前事务版本到原来删除的行
通过MVCC，尽管每行记录都须要额外的存储空间，很多其它的行检查工作以及一些额外的维护工作。但能够降低锁的使用，大多数读操作都不用加锁，读数据操作非常easy，性能非常好，而且也能保证仅仅会读取到符合标准的行。也仅仅锁住必要行。
我们无论从数据库方面的教课书中学到。还是从网络上看到，大都是上文中事务的四种隔离级别这一模块列出的意思，RR级别是可反复读的，但无法解决幻读。而仅仅有在Serializable级别才干解决幻读。
网友评论