当然, 从总的结果来看, 似乎两者都表现为两次读取的结果不一致.
但如果你从控制的角度来看, 两者的区别就比较大
对于前者, 只需要锁住满足条件的记录
对于后者, 要锁住满足条件及其相近的记录
-----------------------------------------------------------
我这么理解是否可以?
避免不可重复读需要锁行就行
避免幻影读则需要锁表
------------------------
####不可重复读和幻读的区别####
很多人容易搞混不可重复读和幻读,确实这两者有些相似。但不可重复读重点在于update和delete,而幻读的重点在于insert。
如果使用锁机制来实现这两种隔离级别,在可重复读中,该sql第一次读取到数据后,就将这些数据加锁,其它事务无法修改这些数据,就可以实现可重复 读了。但这种方法却无法锁住insert的数据,所以当事务A先前读取了数据,或者修改了全部数据,事务B还是可以insert数据提交,这时事务A就会 发现莫名其妙多了一条之前没有的数据,这就是幻读,不能通过行锁来避免。需要Serializable隔离级别 ,读用读锁,写用写锁,读锁和写锁互斥,这么做可以有效的避免幻读、不可重复读、脏读等问题,但会极大的降低数据库的并发能力。
所以说不可重复读和幻读最大的区别,就在于如何通过锁机制来解决他们产生的问题。
上文说的,是使用悲观锁机制来处理这两种问题,但是MySQL、ORACLE、PostgreSQL等成熟的数据库,出于性能考虑,都是使用了以乐观锁为理论基础的MVCC(多版本并发控制)来避免这两种问题。
####悲观锁和乐观锁####
- 悲观锁
正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处 于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机 制,也无法保证外部系统不会修改数据)。
在悲观锁的情况下,为了保证事务的隔离性,就需要一致性锁定读。读取数据时给加锁,其它事务无法修改这些数据。修改删除数据时也要加锁,其它事务无法读取这些数据。
- 乐观锁
相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本( Version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如 果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。
要说明的是,MVCC的实现没有固定的规范,每个数据库都会有不同的实现方式,这里讨论的是InnoDB的MVCC
相关推荐
脏读、不可重复读和幻读都是在事务隔离性不足的情况下可能出现的问题。 1. **脏读**(Dirty Read): - **定义**:当一个事务正在访问数据,并对该数据进行了修改,但这种修改还没有提交到数据库中时,另一个事务...
并发控制的主要目标是避免事务之间的冲突,防止出现诸如脏读、不可重复读和幻读等问题。 脏读发生在事务T1读取了事务T2还未提交的修改数据,然后T2因为某种原因回滚了更改。在这种情况下,T1读到的数据实际上是错误...
2. 读提交(Read Committed):仅能读取已提交的数据,避免脏读,但仍可能遇到不可重复读和幻读。 3. 可重复读(Repeated Read):保证同一事务内的多次读取返回相同数据,防止不可重复读,但幻读仍可能发生,如...
在这种级别下,每次查询都会获取当前的数据库状态,所以可以防止脏读,但不能防止不可重复读和幻读。Oracle 数据库默认采用的就是这个隔离级别。在 MySQL 中,如果我们把两个连接的事务隔离级别都设置为提交读,那么...
包括读未提交(Read Uncommitted)、读已提交(Read Committed)、可重复读(Repeatable Read)和串行化(Serializable),并讨论了这些级别如何影响脏读、不可重复读和幻读的问题。 同时,提供了设置隔离级别的SQL...
这与不可重复读的主要区别在于,不可重复读关注的是已存在的行的修改,而幻读则涉及新行的插入。 MySQL文档指出,幻读只在可重复读、一致性读(Consistent Read,即不锁定读)和读未提交的隔离级别下可能发生,并且...
MySQL的可重复读(Repeatable Read)隔离级别是其事务管理机制的一部分,旨在解决数据库并发操作中的一些问题,如脏读、不可重复读和幻读。然而,标题中提出的问题在于,可重复读隔离级别是否能完全防止幻读。在这个...
数据库的脏读、不可重复读、幻读都和事务的隔离性有关。所以先了解一下事务的4大特性。 事务的4大特性(ACID): 1、原子性(Atomicity):事务是数据库的逻辑工作单位,它对数据库的修改要么全部执行,要么...
4. **串行化**:最高级别的隔离,完全避免了脏读、不可重复读和幻读,但代价是性能降低,因为所有事务都按照序列执行。 为了解决不可重复读问题,数据库管理系统通常会采用锁定策略或者多版本并发控制(MVCC, Multi...
幻读与不可重复读类似,但更关注于数据的新增。在幻读的情况下,一个事务在执行过程中,第二次读取数据时,可能会看到之前未看到的数据记录,这是因为它读取的数据是在此事务开始之后由另一个事务新增的。不可重复读...
尤其是当多个事务并发执行时,可能会遇到一系列的问题,其中就包括脏读、不可重复读和幻读。理解这些问题并知道如何避免它们对于编写健壮的数据库应用程序至关重要。 首先,让我们定义一下这三种问题的含义: 1. ...
- 读已提交(Read Committed):保证一个事务只能读取已经提交的事务所做的修改,可以防止脏读,但不可重复读和幻读仍然可能发生。 - 可重复读(Repeatable Read):确保一个事务中多次读取同一数据时,其结果是一致...
- 串行化(Serializable):最严格的隔离级别,通过锁定所有涉及的行,确保事务按顺序执行,避免脏读、不可重复读和幻读,但可能造成较高的并发性能损失。 在MySQL中,可以通过设置事务隔离级别或使用特定的查询...
然而,它并未解决不可重复读和幻读问题。不可重复读是指在一个事务内,多次读取同一数据集时,结果不同,因为其他事务在此期间对数据进行了修改并提交。幻读则发生在当一个事务按某种条件(如主键或索引)进行查询,...
本文将深入探讨并发事务带来的三种主要问题:脏读、不可重复读和幻读,以及MySQL如何通过事务隔离级别来解决这些问题。 首先,脏读(Dirty Reads)指的是一个事务读取到了另一个未提交事务的数据,导致数据的不一致...
1. **读未提交(Read Uncommitted)**:这是最低的隔离级别,允许事务读取其他未提交的事务数据,可能导致脏读、不可重复读和幻读问题。 2. **读已提交(Read Committed)**:每个事务只能看到其他已经提交的事务...
2. 读已提交(Read Committed):在这个级别,一个事务只能读取其他事务已经提交的数据,避免了脏读,但仍然可能存在不可重复读和幻读。 3. 可重复读(Repeatable Read):这个级别防止了脏读和不可重复读,但在...
4. **幻读、不可重复读和脏读的区别**: - **脏读**:读取到未提交的数据。 - **不可重复读**:在同一事务内多次查询同一数据,结果不同,因为其他事务已提交了修改。 - **幻读**:在事务内多次执行相同的查询,...