深入分析事物的隔离级别

什么是事务
事务（Transaction）：访问并可能更新数据库中各种数据项的一个程序执行单元（unit），它通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起。当在数据库中更改数据成功时，在事务中更改的数据便会提交，不再改变。否则，事务就取消或者回滚，更改无效。

事务解释：指要做的或所做的事情

事务本质：一系列操作

事务特性：事务是恢复和并发控制的基本单位。

 

例如    网上购物，其交易过程至少包括以下几个步骤的操作：

更改客户所购商品的库存信息；
保存客户付款信息；
生成订单并且保存到数据库中；
更改用户相关信息，例如购物数量等。
在正常情况下，这些操作都将顺利进行，最终交易成功，与交易相关的所有数据库信息也成功地更新。但是，如果在执行的途中遇到突然断电或者其他意外情况，导致这一系列过程中任何一个环节出了差错，例如在更细商品库存信息时发生异常、顾客银行账户余额不足等，都将导致整个交易过程失败。而一旦失败，数据库中所有信息都必须保持交易不影响数据库的状态，即原有的库存信息没有被更新、用户也没有付款、订单也没有生成。否则，数据库的信息将会不一致，或者出现更为严重的不可预测的后果。数据库事务正是用来保证这种情况下交易的平稳性和可预测性的技术。
 

事务的属性
事务必须满足四个属性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），即ACID四种属性。

（1）原子性
一个事务是一个不可分割的整体，为了保证事务的总体目标，事务必须具有原子性，即当数据修改时，要么全都执行，要么全都不执行。即，不允许事务部分地完成，避免了只执行这些操作的一部分而带来的错误。

（2）一致性
一个事务在执行之前和执行之后，数据库数据必须保持一致性。数据库的一致性状态应该满足模式锁指定的约束条件，那么在完整执行该事务后，数据库仍然处于一致性状态。

例如：银行转账，转账前后两个账户金额之和应保持不变。

（3）隔离性
由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据库时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。

例如：对任何一对事务T1和T2，对T1而言，T2要么在T1开始之前已经结束，要么在T1完成之后再开始执行。

（4）持久性
也被称为永久性，事务完成以后，DBMS（数据库管理系统）保证它对数据库中数据的修改是永久性的，当系统或介质发生故障时，该修改也永久保持。持久性一般通过数据库备份与恢复来保证。

注意    严格而言，数据库事务属性都是由数据库管理系统来进行保证的，在整个应用程序的运行过程中，应用程序无须去考虑数据库的ACID实现。
一般情况下，通过执行COMMIT（提交）或ROLLBACK（回滚）语句来终止事务。当执行COMMIT语句时，自从事务启动以来对数据库所做的一切更改就成为永久性的，即被写入到磁盘，而当执行ROLLBACK语句时，自从事务启动以来对数据库所做的一切更改都会被撤销，并且数据库中内容返回到事务开始之前所处的状态。无论什么情况，在事务完成时，都能保证回到一致性状态。

并发控制
（1）DBS（数据库系统）一个明显的特点是多个用户共享数据库资源，尤其是多个用户可以同时存取相同数据。

串行控制：如果事务是顺序执行的，即一个事务完成之后，再开始另一事务。
并行控制：如果DBMS可以同时接受多个事务，并且这些事务在时间上可以重叠执行。
（2）并发控制概述

事务是并发控制的基本单位，保证事务ACID的特性是事务处理的重要任务，而并发操作有可能会破坏其ACID特性。

DBMS并发控制机制的责任：对并发操作进行正确调度，保证事务的隔离更一般，确保数据库的一致性。

由于并发操作带来的数据不一致性
如果没有锁定且多个用户同时访问一个数据库，则当他们的事务同时使用相同的数据时可能会发生问题。由于并发操作带来的数据不一致性包括：丢失数据更新、读“脏”数据（脏读）、不可重复读。

（1）更新丢失
两个事务都同时更新一行数据，一个事务对数据的更新把另一个事务对数据的更新覆盖了。这是因为系统没有执行任何的锁操作，因此并发并没有被隔离开来。

（2）脏读
一个事务读取到了另一事务未提交的数据操作结果。这是相当危险的，因为很可能所有的操作都被回滚。

（3）不可重复读
不可重复读（Non-repeatable Reads）：一个事务对同一行数据重复读取两次，但是却得到了不同的结果。

包括以下情况：

虚读：事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读取该数据时得到与前一次不同的值。
幻读：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据。这是因为在两次查询过程中有另外一个事务插入数据造成的。

事务隔离级别
为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。

读未提交（Read Uncommitted）：只处理更新丢失。如果一个事务已经开始写数据，则不允许其他事务同时进行写操作，但允许其他事务读此行数据。可通过“排他写锁”实现。
读提交（Read Committed）：处理更新丢失、脏读。读取数据的事务允许其他事务继续访问改行数据，但是未提交的写事务将会禁止其他事务访问改行。可通过“瞬间共享读锁”和“排他写锁”实现。
可重复读取（Repeatable Read）：处理更新丢失、脏读和不可重复读取。读取数据的事务将会禁止写事务，但允许读事务，写事务则禁止任何其他事务。可通过“共享读锁”和“排他写锁”实现。
序列化（Serializable）：提供严格的事务隔离。要求失去序列化执行，事务只能一个接一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

 

未提交读(Read uncommitted)

未提交读(READ UNCOMMITTED)是最低的隔离级别。通过名字我们就可以知道，在这种事务隔离级别下，一个事务可以读到另外一个事务未提交的数据。

未提交读的数据库锁情况（实现原理）

事务在读数据的时候并未对数据加锁。

务在修改数据的时候只对数据增加行级共享锁。

现象：

事务1读取某行记录时，事务2也能对这行记录进行读取、更新（因为事务一并未对数据增加任何锁）

当事务2对该记录进行更新时，事务1再次读取该记录，能读到事务2对该记录的修改版本（因为事务二只增加了共享读锁，事务一可以再增加共享读锁读取数据），即使该修改尚未被提交。

事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。（因为事务一对数据增加了共享读锁，事务二不能增加排他写锁进行数据的修改）

举例

下面还是借用我在数据库的读现象浅析一文中举的例子来说明在未提交读的隔离级别中两个事务之间的隔离情况。

事务一	事务二
/* Query 1 */ SELECT age FROM users WHERE id = 1; /* will read 20 */
	/* Query 2 */  UPDATE users SET age = 21 WHERE id = 1; /* No commit here */
/* Query 1 */ SELECT age FROM users WHERE id = 1; /* will read 21 */
	ROLLBACK; /* lock-based DIRTY READ */

事务一共查询了两次，在两次查询的过程中，事务二对数据进行了修改，并未提交（commit）。但是事务一的第二次查询查到了事务二的修改结果。在数据库的读现象浅析中我们介绍过，这种现象我们称之为脏读。

所以，未提交读会导致脏读

提交读(Read committed)

提交读(READ COMMITTED)也可以翻译成读已提交，通过名字也可以分析出，在一个事务修改数据过程中，如果事务还没提交，其他事务不能读该数据。

提交读的数据库锁情况

事务对当前被读取的数据加 行级共享锁（当读到时才加锁），一旦读完该行，立即释放该行级共享锁；

事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。

现象：

事务1在读取某行记录的整个过程中，事务2都可以对该行记录进行读取（因为事务一对该行记录增加行级共享锁的情况下，事务二同样可以对该数据增加共享锁来读数据。）。

事务1读取某行的一瞬间，事务2不能修改该行数据，但是，只要事务1读取完改行数据，事务2就可以对该行数据进行修改。（事务一在读取的一瞬间会对数据增加共享锁，任何其他事务都不能对该行数据增加排他锁。但是事务一只要读完该行数据，就会释放行级共享锁，一旦锁释放，事务二就可以对数据增加排他锁并修改数据）

事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。（事务一在更新数据的时候，会对该行数据增加排他锁，知道事务结束才会释放锁，所以，在事务二没有提交之前，事务一都能不对数据增加共享锁进行数据的读取。所以，提交读可以解决脏读的现象）

举例

事务一	事务二
/* Query 1 */ SELECT * FROM users WHERE id = 1;
	/* Query 2 */  UPDATE users SET age = 21 WHERE id = 1; COMMIT; /* in multiversion concurrency control, or lock-based READ COMMITTED */
/* Query 1 */ SELECT * FROM users WHERE id = 1; COMMIT;  /*lock-based REPEATABLE READ */

在提交读隔离级别中，在事务二提交之前，事务一不能读取数据。只有在事务二提交之后，事务一才能读数据。

但是从上面的例子中我们也看到，事务一两次读取的结果并不一致，所以提交读不能解决不可重复读的读现象。

简而言之，提交读这种隔离级别保证了读到的任何数据都是提交的数据，避免了脏读(dirty reads)。但是不保证事务重新读的时候能读到相同的数据，因为在每次数据读完之后其他事务可以修改刚才读到的数据。

可重复读(Repeatable reads)

可重复读(REPEATABLE READS),由于提交读隔离级别会产生不可重复读的读现象。所以，比提交读更高一个级别的隔离级别就可以解决不可重复读的问题。这种隔离级别就叫可重复读（这名字起的是不是很任性！！）

可重复读的数据库锁情况

事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加 行级共享锁，直到事务结束才释放；

事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。

现象

事务1在读取某行记录的整个过程中，事务2都可以对该行记录进行读取（因为事务一对该行记录增加行级共享锁的情况下，事务二同样可以对该数据增加共享锁来读数据。）。

事务1在读取某行记录的整个过程中，事务2都不能修改该行数据（事务一在读取的整个过程会对数据增加共享锁，直到事务提交才会释放锁，所以整个过程中，任何其他事务都不能对该行数据增加排他锁。所以，可重复读能够解决不可重复读的读现象）

事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。（事务一在更新数据的时候，会对该行数据增加排他锁，知道事务结束才会释放锁，所以，在事务二没有提交之前，事务一都能不对数据增加共享锁进行数据的读取。所以，提交读可以解决脏读的现象）

举例

事务一	事务二
/* Query 1 */ SELECT * FROM users WHERE id = 1; COMMIT;
	/* Query 2 */  UPDATE users SET age = 21 WHERE id = 1; COMMIT; /* in multiversion concurrency control, or lock-based READ COMMITTED */

在上面的例子中，只有在事务一提交之后，事务二才能更改该行数据。所以，只要在事务一从开始到结束的这段时间内，无论他读取该行数据多少次，结果都是一样的。

从上面的例子中我们可以得到结论：可重复读隔离级别可以解决不可重复读的读现象。但是可重复读这种隔离级别中，还有另外一种读现象他解决不了，那就是幻读。看下面的例子：

事务一	事务二
/* Query 1 */ SELECT * FROM users WHERE age BETWEEN 10 AND 30;
	/* Query 2 */  INSERT INTO users VALUES ( 3, 'Bob', 27 ); COMMIT;
/* Query 1 */ SELECT * FROM users WHERE age BETWEEN 10 AND 30;

上面的两个事务执行情况及现象如下：

1.事务一的第一次查询条件是age BETWEEN 10 AND 30;如果这是有十条记录符合条件。这时，他会给符合条件的这十条记录增加行级共享锁。任何其他事务无法更改这十条记录。

2.事务二执行一条sql语句，语句的内容是向表中插入一条数据。因为此时没有任何事务对表增加表级锁，所以，该操作可以顺利执行。

3.事务一再次执行SELECT * FROM users WHERE age BETWEEN 10 AND 30;时，结果返回的记录变成了十一条，比刚刚增加了一条，增加的这条正是事务二刚刚插入的那条。

所以，事务一的两次范围查询结果并不相同。这也就是我们提到的幻读。

可序列化(Serializable)

可序列化(Serializable)是最高的隔离级别，前面提到的所有的隔离级别都无法解决的幻读，在可序列化的隔离级别中可以解决。

我们说过，产生幻读的原因是事务一在进行范围查询的时候没有增加范围锁(range-locks：给SELECT 的查询中使用一个“WHERE”子句描述范围加锁），所以导致幻读。

可序列化的数据库锁情况

事务在读取数据时，必须先对其加 表级共享锁 ，直到事务结束才释放；

事务在更新数据时，必须先对其加 表级排他锁 ，直到事务结束才释放。

现象

事务1正在读取A表中的记录时，则事务2也能读取A表，但不能对A表做更新、新增、删除，直到事务1结束。(因为事务一对表增加了表级共享锁，其他事务只能增加共享锁读取数据，不能进行其他任何操作）

事务1正在更新A表中的记录时，则事务2不能读取A表的任意记录，更不可能对A表做更新、新增、删除，直到事务1结束。（事务一对表增加了表级排他锁，其他事务不能对表增加共享锁或排他锁，也就无法进行任何操作）

虽然可序列化解决了脏读、不可重复读、幻读等读现象。但是序列化事务会产生以下效果：

1.无法读取其它事务已修改但未提交的记录。

2.在当前事务完成之前，其它事务不能修改目前事务已读取的记录。

3.在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。

 

 

本文资料参考:   https://blog.csdn.net/weixin_39651041/article/details/79980202

                          https://www.cnblogs.com/wajika/p/6680196.html