PostgreSQL中事务的隔离级别

（1）读未提交（READ UNCOMMITTED）

（2）读已提交（READ COMMITTED）

（3）重复读（REPEATABLE READ）

（4）串行化（SERIALIZABLE）

    对于并发事务，我们不希望发生的行为如下：

（1）脏读：一个事务读取了另一个未提交的事务写入的数据。

（2）不可重复读：一个事务重新读取前面读取过的数据时，发现该数据已改变。

（3）幻读：一个事务开始后，需要根据数据库中现有的数据做一些更新，于是重新执行一个查询，返回符合查询条件的行，这时发现这些行因为其它最近提交的事务而发生了改变，导致现有事务如果再进行下去可能发发生逻辑上的错误。

    不同事务隔离级别的行为见表：

隔离级别 脏读 不可重复读 幻读读未提交可能可能可能读已提交不可能可能可能重复读不可能不可能可能可串行化不可能不可能不可能PostgreSQL里默认的隔离级别是"读已提交"。

如何很好的理解不可重复读和幻读的区别：

精炼解释：

不可重复读的重点是修改:

同样的条件, 你读取过的数据, 再次读取出来发现值不一样了幻读的重点在于新增或者删除

同样的条件, 第1次和第2次读出来的记录数不一样

当然, 从总的结果来看, 似乎两者都表现为两次读取的结果不一致.但如果你从控制的角度来看, 两者的区别就比较大对于前者, 只需要锁住满足条件的记录对于后者, 要锁住满足条件及其相近的记录

详细说明：

1) "不可重复读" 是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题要避免这种情况，通常可以用 set tran isolation level repeatable read 来设置隔离级别，这样事务A 在两次读取表T中的数据时，事务B如果企图更改表T中的数据（细节到事务A读取数据）时，就会被阻塞，知道事务A提交！ 这样就保证了，事务A两次读取的数据的一致性。2）幻觉读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。

PostgreSQL中事务的隔离级别

标签：取数   四种   结果   tran   就会   隔离   level   table   comm   

小编还为您整理了以下内容，可能对您也有帮助：

数据库事务隔离级别有哪些

数据库事务隔离级别有哪些如下：

事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。事物的并发操作中可能休闲脏读，不可重复读，幻读。

1、第一种隔离级别：Read uncommitted（读未提交）

如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据，该隔离级别可以通过“排他写锁”，但是不排斥读线程实现。这样就避免了更新丢失，却可能出现脏读，也就是说事务B读取到了事务A未提交的数据。

解决了更新丢失，但还是可能会出现脏读。

2、第二种隔离级别：Read committed（读提交）

如果是一个读事务(线程)，则允许其他事务读写，如果是写事务将会禁止其他事务访问该行数据，该隔离级别避免了脏读，但是可能出现不可重复读。事务A事先读取了数据，事务B紧接着更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。

解决了更新丢失和脏读问题。

3、第三种隔离级别：Repeatable read（可重复读取）

可重复读取是指在一个事务内，多次读同一个数据，在这个事务还没结束时，其他事务不能访问该数据，这样就可以在同一个事务内两次读到的数据是一样的，因此称为是可重复读隔离级别，读取数据的事务将会禁止写事务，写事务则禁止任何其他事务，这样避免了不可重复读和脏读，但是有时可能会出现幻读。

读取数据的事务可以通过“共享读镜”和“排他写锁”实现。

解决了更新丢失、脏读、不可重复读、但是还会出现幻读。

4、第四种隔离级别：Serializable（可序化）

提供严格的事务隔离，它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行，如果仅仅通过“行级锁”是无法实现序列化的，必须通过其他机制保证新插入的数据不会被执行查询操作的事务访问到。

事务的隔离级别是什么?

数据库事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻读。

1、Read uncommitted

读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。

2、Read committed

读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。

3、Repeatable read

重复读，就是在开始读取数据（事务开启）时，不再允许修改操作。

4、Serializable 序列化

Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

事务的隔离级别是什么?

数据库事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻读。

1、Read uncommitted

读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。

2、Read committed

读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。

3、Repeatable read

重复读，就是在开始读取数据（事务开启）时，不再允许修改操作。

4、Serializable 序列化

Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

标准SQL规范中定义的四个事务隔离级别

在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同:

　　◆未授权读取(Read Uncommitted)：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

　　◆授权读取(Read Committed)：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

　　◆可重复读取(Repeatable Read)：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务)，写事务则禁止任何其他事务。

　　◆序列化(Serializable)：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

　　隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

　　通过前面的介绍已经知道，通过选用不同的隔离等级就可以在不同程度上避免前面所提及的在事务处理中所面临的各种问题。所以，数据库隔离级别的选取就显得尤为重要，在选取数据库的隔离级别时，应该注意以下几个处理的原则：

　　首先，必须排除“未授权读取”，因为在多个事务之间使用它将会是非常危险的。事务的回滚操作或失败将会影响到其他并发事务。第一个事务的回滚将会完全将其他事务的操作清除，甚至使数据库处在一个不一致的状态。很可能一个已回滚为结束的事务对数据的修改最后却修改提交了，因为“未授权读取”允许其他事务读取数据，最后整个错误状态在其他事务之间传播开来。

　　其次，绝大部分应用都无须使用“序列化”隔离(一般来说，读取幻影数据并不是一个问题)，此隔离级别也难以测量。目前使用序列化隔离的应用中，一般都使用悲观锁，这样强行使所有事务都序列化执行。

　　剩下的也就是在“授权读取”和“可重复读取”之间选择了。我们先考虑可重复读取。如果所有的数据访问都是在统一的原子数据库事务中，此隔离级别将消除一个事务在另外一个并发事务过程中覆盖数据的可能性(第二个事务更新丢失问题)。这是一个非常重要的问题，但是使用可重复读取并不是解决问题的途径。

　　假设使用了“版本数据”，Hibernate会自动使用版本数据。Hibernate的一级Session缓存和版本数据已经为你提供了“可重复读取隔离”绝大部分的特性。特别是，版本数据可以防止二次更新丢失的问题，一级Session缓存可以保证持久载入数据的状态与其他事务对数据的修改隔离开来，因此如果使用对所有的数据库事务采用授权读取隔离和版本数据是行得通的。

　　“可重复读取”为数据库查询提供了更好的效率(仅对那些长时间的数据库事务)，但是由于幻影读取依然存在，因此没必要使用它(对于Web应用来说，一般也很少在一个数据库事务中对同一个表查询两次)。

　　也可以同时考虑选择使用Hibernate的二级缓存，它可以如同底层的数据库事务一样提供相同的事务隔离，但是它可能弱化隔离。假如在二级缓存大量使用缓存并发策略，它并不提供重复读取语义(例如，后面章节中将要讨论的读写，特别是非严格读写)，很容易可以选择默认的隔离级别：因为无论如何都无法实现“可重复读取”，因此就更没有必要拖慢数据库了。另一方面，可能对关键类不采用二级缓存，或者采用一个完全的事务缓存，提供“可重复读取隔离”。那么在业务中需要使用到“可重复读取”吗?如果你喜欢，当然可以那样做，但更多的时候并没有必要花费这个代价。

事务隔离的四个级别是什么?

事务隔离的四个级别是未提交读（Read Uncommitted）、提交读（Read Committed）、可重复读（Repeable Read）、可串行化（Serializable）。

1、未提交读（Read Uncommitted）：事务可以读取未提交的数据，也称作脏读（Dirty Read）。一般很少使用。

2、提交读（Read Committed）：是大都是DBMS（如：Oracle，SQLServer）默认事务隔离。执行两次同意的查询却有不同的结果，也叫不可重复读。

3、可重复读（Repeable Read）：是MySQL默认事务隔离级别。能确保同一事务多次读取同一数据的结果是一致的。可以解决脏读的问题，但理论上无法解决幻读（Phantom Read）的问题。

4、可串行化（Serializable）：是最高的隔离级别。强制事务串行执行，会在读取的每一行数据上加锁，这样虽然能避免幻读的问题，但也可能导致大量的超时和锁争用的问题。很少会应用到这种级别，只有在非常需要确保数据的一致性且可以接受没有并发的应用场景下才会考虑。

事务隔离级别特点比较

从事务隔离级别的定义上可以看出，Serializable级别隔离性最高，但是其效率也最低，因为其要求所有操作相同记录的事务都串行的执行。

对于MySql而言，其默认事务级别是Repeatable read，虽然在定义上讲，这种隔离级别无法解决幻读的问题，但是MySql使用了一种Next key-lock的算法来实现Repeatable read，这种算法是能够解决幻读问题的。

关于Next key-lock算法，在进行查询时，其不仅会将当前的操作记录锁住，也会将查询所涉及到的范围锁住。

也就是说，其他事务如果想要在当前事务查询的范围内进行数据操作，那么其是会被阻塞的，因而MySql在Repeatable read隔离级别下就已经具备了Serializable隔离级别的事务隔离性。

以上内容参考：百度百科-隔离级别

事务隔离的四个级别是什么?

事务隔离的四个级别是未提交读（Read Uncommitted）、提交读（Read Committed）、可重复读（Repeable Read）、可串行化（Serializable）。

1、未提交读（Read Uncommitted）：事务可以读取未提交的数据，也称作脏读（Dirty Read）。一般很少使用。

2、提交读（Read Committed）：是大都是DBMS（如：Oracle，SQLServer）默认事务隔离。执行两次同意的查询却有不同的结果，也叫不可重复读。

3、可重复读（Repeable Read）：是MySQL默认事务隔离级别。能确保同一事务多次读取同一数据的结果是一致的。可以解决脏读的问题，但理论上无法解决幻读（Phantom Read）的问题。

4、可串行化（Serializable）：是最高的隔离级别。强制事务串行执行，会在读取的每一行数据上加锁，这样虽然能避免幻读的问题，但也可能导致大量的超时和锁争用的问题。很少会应用到这种级别，只有在非常需要确保数据的一致性且可以接受没有并发的应用场景下才会考虑。

事务隔离级别特点比较

从事务隔离级别的定义上可以看出，Serializable级别隔离性最高，但是其效率也最低，因为其要求所有操作相同记录的事务都串行的执行。

对于MySql而言，其默认事务级别是Repeatable read，虽然在定义上讲，这种隔离级别无法解决幻读的问题，但是MySql使用了一种Next key-lock的算法来实现Repeatable read，这种算法是能够解决幻读问题的。

关于Next key-lock算法，在进行查询时，其不仅会将当前的操作记录锁住，也会将查询所涉及到的范围锁住。

也就是说，其他事务如果想要在当前事务查询的范围内进行数据操作，那么其是会被阻塞的，因而MySql在Repeatable read隔离级别下就已经具备了Serializable隔离级别的事务隔离性。

以上内容参考：百度百科-隔离级别

事务隔离级别的解决方案

为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。 序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

事务隔离级别的解决方案

为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。 序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

事务的隔离级别有哪些

大多数的数据库默认隔离级别为：Read Commited 比如 sql server、Oracle少数数据库默认隔离级别为：Repeatable Read 比如： MySql InnoDB 1、脏读：(事务没有提交，提前读取) ：当一个事务正在访问数据库，并且对数据进行修改 而这种修改还没有提交到数据库中，这是，另外一个事物访问数据库，然后使用了这个数据。 2、不可重复读（两次读的数据不一致） 一个事务内，多次读同一个数据，在这个事务还没有结束时，另外一个事务也访问该同一个数据，那么在一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次分别读取的数据可能会不一样，这样就发生了一个事务内两次读到的数据不一致。 3、幻读：当事务不是执行时发生的一种现象，例如：第一个事务对一个表中的数据进行修改，这种修改涉及到表中的全部数据行，同时，第二个事务也修改这个表中的数据，这种修改时向表中插入一行新数据，那么以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好像幻觉一样。 4.第一类更新丢失(回滚丢失)：

当2个事务更新相同的数据源，如果第一个事务被提交，而另外一个事务却被撤销，那么会连同第一个事务所做的跟新也被撤销。也就是说第一个事务做的跟新丢失了。

5.第二类更新丢失(覆盖丢失)：

第二类更新丢失实在实际应用中经常遇到的并发问题，他和不可重复读本质上是同一类并发问题，通常他被看做不可重复读的特例：当2个或这个多个事务查询同样的记录然后各自基于最初的查询结果更新该行时，会造成第二类丢失更新。因为每个事务都不知道不知道其他事务的存在，最后一个事务对记录做的修改将覆盖其他事务对该记录做的已提交的跟新... Isolation （隔离）属性一共支持五种事务设置，具体介绍如下：

DEFAULT （默认）使用数据库设置的隔离级别，由 DBA 默认的设置来决定隔离级别 .

READ_UNCOMMITTED 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 )

READ_COMMITTED 会出现不可重复读、幻读问题（锁定正在读取的行）

REPEATABLE_READ 会出幻读（锁定所读取的所有行）

SERIALIZABLE 保证所有的情况不会发生（锁表）

不可重复读的重点是修改 :

同样的条件 , 你读取过的数据 , 再次读取出来发现值不一样了

幻读的重点在于新增或者删除同样的条件 , 第 1 次和第 2 次读出来的记录数不一样

数据隔离四个级别分别是哪些

数据库的四个级别分为：读取未提交内容，读取提交内容，可重读以及可串行化。但隔离级别也会造成脏读，不可重复读以及幻读等问题
【推荐课程：MySQL教程】
数据库隔离的四个级别分别为：
Read Uncommitted（读取未提交内容）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
Read Committed（读取提交内容）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
Repeatable Read（可重读）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
Serializable（可串行化）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。
隔离级别所产生的问题
这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：
脏读(Drity Read)：
某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。
不可重复读(Non-repeatable read):
在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。
幻读(Phantom Read):
在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。
在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：
隔离级别脏读不可重复读
幻读读未提交√√√读已提交X√√可重复读XX√可串行化XXX总结：

数据隔离四个级别分别是哪些

数据库的四个级别分为：读取未提交内容，读取提交内容，可重读以及可串行化。但隔离级别也会造成脏读，不可重复读以及幻读等问题
【推荐课程：MySQL教程】
数据库隔离的四个级别分别为：
Read Uncommitted（读取未提交内容）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
Read Committed（读取提交内容）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
Repeatable Read（可重读）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
Serializable（可串行化）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。
隔离级别所产生的问题
这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：
脏读(Drity Read)：
某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。
不可重复读(Non-repeatable read):
在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。
幻读(Phantom Read):
在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。
在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：
隔离级别脏读不可重复读
幻读读未提交√√√读已提交X√√可重复读XX√可串行化XXX总结：

数据库事务隔离级别 一般用哪个

术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。

隔离级别的产生

在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。

所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。

事务的4种隔离级别

READ UNCOMMITTED       未提交读，可以读取未提交的数据。READ COMMITTED         已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句，                       InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。                       Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ        可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE           序列化

在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；

SQL 语句根据条件扫描到的可能需要加锁的数据范围；

以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）

1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）

整形，对值具有唯一约束条件的数据范围 1～5 ，

已有数据1、2、3、4、5，此时数据范围已被完全填充；

整形，对值具有唯一约束条件的数据范围 1 和 5 ，

已有数据1、5，此时数据范围已被完全填充； 

2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）

整形的数据范围 1～5 ，

已有数据 1、2、3、4、5，但是因为没有唯一约束，

所以数据范围可以继续被 1～5 的数据重复填充；

整形，具有唯一约束条件的数据范围 1～5 ，

已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；

3. 数据范围内没有任何数据（存在间隙）

如下：

整形的数据范围 1～5 ，数据范围内当前没有任何数据。

在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。

无控制的并发所带来的问题

并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。

1. 范围内已有数据更改导致的：

更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，

由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；

脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。

这时，另外一个事务也来读取同一条记录，如果不加控制，

第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。

这种现象就叫“脏读”。

2. 范围内数据量发生了变化导致：

不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，

却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。

这种现象就叫“不可重复读”。

幻读：一个事务按相同的查询条件重新读取以前检索过的数据，

却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。

可以简单的认为满足条件的数据量变化了。

因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。

MySQL 隔离级别的实现

InnoDB 通过加锁的策略来支持这些隔离级别。

行锁包含：

Record Locks

索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，

这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。

Gap Locks

间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。

间隙锁是性能和并发之间权衡的一部分。

对于无间隙的数据范围不需要间隙锁，因为没有间隙。

Next-Key Locks

索引记录上的记录锁和索引记录之前的 gap lock 的组合。

假设索引包含 10、11、13 和 20。

可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：

(负无穷大, 10]    (10, 11]    (11, 13]    (13, 20]    (20, 正无穷大)        对于最后一个间隔，next-key将会锁定索引中最大值的上方，

左右滑动进行查看

"上确界"伪记录的值高于索引中任何实际值。

上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。

基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。

对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。

默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。

READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。

对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，

以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。

总结&延展：

唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。

当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。

行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。

例如，

在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。

session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。

session A 通过索引 idA，session B通过索引 idB 。

当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。

比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。

间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。

rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。

rr 模式下，为了防止幻读，会加上 Gap Locks。

事务中，SQL 开始则加锁，事务结束才释放锁。

就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。

就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。

锁只是并发控制的一种粒度，只是一个很小的部分：

从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)

并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)

相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)

粒度加载的安全&性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。

事务和锁机制是什么关系？ 开启事务就自动加锁了吗？

1、事务与锁是不同的。事务具有ACID（原子性、一致性、隔离性和持久性），锁是用于解决隔离性的一种机制。

2、事务的隔离级别通过锁的机制来实现。另外锁有不同的粒度，同时事务也是有不同的隔离级别的。

3、开启事务就自动加锁。

ql规范定义的事务的隔离级别：

1.READ UNCOMMITTED(读取未提交内容)

所有事务可以看到未提交事务的执行结果，本隔离级别很少用到实际应用中，读取未提交的数据，又称为“脏读”。

2.READ COMMITTED（读取提交内容）

大多数数据库的默认隔离级别是此级别，但不是MySQL默认的。一个事务在开始的时候只能看见已提交事务所做的改变。一个事务从开始到提交前所做的任何改变都是不可见的，除非提交。这种隔离级别也称为不可重复读。

3.REPEATABLE READ(可重复读)

此隔离级别是为了解决可重复读隔离级别导致的问题即一个事务多个实例并发读取数据时会看到不同的结果。此隔离级别不会看到其他事务提交后的结果，即事务即使提交了我也看不到。此级别也称为“幻读”。

4.SERIALIZABLE(可串行化)

可串行化是最高的隔离级别，它通过强制事务排序，使之不可重读，解决了幻读的问题。此隔离级别会在每个读的数据行上加共享锁，使用这种隔离级别会产生大量的超时现象，一般实际开发中不会用到。

mysql加锁机制:

根据类型可分为共享锁（SHARED LOCK）和排他锁（EXCLUSIVE LOCK）或者叫读锁（READ LOCK）和写锁（WRITE LOCK）。

根据粒度划分又分表锁和行锁。表锁由数据库服务器实现，行锁由存储引擎实现。

mysql提供了3种事务型存储引擎，InnDB、NDB Cluster和Falcon。

一个事务执行的任何过程中都可以获得锁，但是只有事务提交或回滚的时候才释放这些锁。这些都是隐式锁定，也可以显式锁定，InnoDB支持显式锁定，例如：

SELECT .... LOCK IN SHARE MODE (加共享锁)

SELECT .....FOR UPDATE(加排他锁)

多版本并发控制（重要）：

Mysql的事务存储引擎不是简单实用行加锁机制，而是叫多版本并发控制（MVCC）技术，和行加锁机制关联实用。以便应对更高的并发，当然是以消耗性能作为代价。

每种存储引擎对MVCC的实现方式不同，InnoDB引擎的简单实现方式如下：

InnoDB通过为每个数据航增加两个隐含值的方式来实现。这两个隐含值记录了行的创建时间，以及过期时间。每一行存储事件发生时的系统版本号。每一次开始一个新事务时版本号会自动加1，每个事务都会保存开始时的版本号，每个查询根据事务的版本号来查询结果。

MySQL使用以下几种机制进行隔离性的实现：         a.锁机制             通过使用加锁机制，使用其它事务无法到读某事务末提交前的数据更新，解决脏读问题；             mySQL 有：共享锁，排他锁，根据粒度，有行锁，表锁。         b.MVCC机制：          事务存储引擎使用多版本并发控制（MVCC）技术，和行加锁机制关联使用         MySQL 的InnoDB,XtraDB 引擎通过 使用MVCC 来解决幻读问题。