mysql幻影读怎么解决_MYSQL如何解决幻读

本文详细介绍了MySQL数据库的四种事务隔离级别:READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ和SERIALIZABLE,重点讲解了可重复读(REPEATABLE READ)级别下如何解决幻读问题。MySQL的InnoDB存储引擎通过多版本并发控制(MVCC)实现非阻塞读操作,利用行的创建和过期时间系统版本号来避免幻读。在MVCC的帮助下,INSERT, DELETE, UPDATE操作得以高效执行,同时保证了在REPEATABLE READ隔离级别下的数据一致性。" 88423040,5651836,Java字符流详解:从Reader到BufferedWriter,"['Java', 'IO流', '字符流']

首先要了解下mysql数据库的事务特征之一隔离级别:

READ UNCOMMITTED(未提交读):

在READUNCOMMITTED级别,事务中的修改,即使没有提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为脏读(DirtyRead)。这个级别会导致很多问题,从性能上来说,READUNCOMMITTED不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。

READ COMMITTED( 提交读)

大多数数据库系统的默认隔离级别都是READCOMMITTED(但MySQL不是)。READCOMMITTED满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读(nonrepeatableread),因为两次执行同样的查询,可能会得到不一样的结果。

REPEATABLE READ( 可重复读)

REPEATABLEREAD解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上,可重复读隔离级别还是无法解决另外一个幻读(PhantomRead)的问题。所谓幻读,指的是当某个事务在读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录,当之前的事务再次读取该范围的记录时,会产生幻行(PhantomRow)。InnoDB和XtraDB存储引擎通过多版本并发控制(MVCC,MultiversionConcurrencyControl)解决了幻读的问题。本章稍后会做进一步的讨论。可重复读是MySQL的默认事务隔离级别。

SERIALIZABLE(可串行化)

SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行,避免了前面说的幻读的问题。简单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别,只有在非常需要确保数据的一致性而且可以接受没有并发的情况下,才考虑采用该级别。

第二部分

MVCC是如何解决幻读的呢,来,

MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑,它们一般都同时实现了多版本并发控制(MVCC)。不仅是MySQL,包括Oracle、PostgreSQL等其他数据库系统也都实现了MVCC,但各自的实现机制不尽相同,因为MVCC没有一个统一的实现标准。

可以认为MVCC是行级锁的一个变种,但是它在很多情况下避免了加锁操作,因此开销更低。虽然实现机制有所不同,但大都实现了非阻塞的读操作,写操作也只锁定必要的行。

MVCC的实现,是通过保存数据在某个时间点的快照来实现的。也就是说,不管需要执行多长时间,每个事务看到的数据都是一致的。根据事务开始的时间不同,每个事务对同一张表,同一时刻看到的数据可能是不一样的。如果之前没有这方面的概念,这句话听起来就有点迷惑。熟悉了以后会发现,这句话其实还是很容易理解的。

前面说到不同存储引擎的MVCC实现是不同的,典型的有乐观(optimistic)并发控制控制和悲观(pessimistic)并发控制。

下面我们通过InnoDB的简化版行为来说明MVCC是如何工作的。

InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的。这两个列,一个保存了行的创建时间,一个保存行的过期时间(或删除时间)。当然存储的并不是实际的时间值,而是系统版本号(systemversionnumber)。每开始一个新的事务,系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号,用来和查询到的每行记录的版本号进行比较。下面看一下在REPEATABLEREAD隔离级别下,MVCC具体是如何操作的。

SELECT    InnoDB会根据以下两个条件检查每行记录:InnoDB只查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号),这样可以确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的。行的删除版本要么未定义,要么大于当前事务版本号。这可以确保事务读取到的行,在事务开始之前未被删除。只有符合上述两个条件的记录,才能返回作为查询结果。

INSERT    InnoDB为新插入的每一行保存当前系统版本号作为行版本号。

DELETE    InnoDB为删除的每一行保存当前系统版本号作为行删除标识。

UPDATE   InnoDB为插入一行新记录,保存当前系统版本号作为行版本号,同时保存当前系统版本号到原来的行作为行删除标识。保存这两个额外系统版本号,使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单,性能很好,并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间,需要做更多的行检查工作,以及一些额外的维护工作。MVCC只在REPEATABLEREAD和READCOMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容(4),因为READUNCOMMITTED总是读取最新的数据行,而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

### 如何在 MySQL 中防止或解决问题 #### 使用不同隔离级别 在 `REPEATABLE READ` 隔离级别下,尽管 InnoDB 存储引擎利用多版本并发控制 (MVCC) 来提供数据一致性视图并减少锁争用,但在某些情况下仍可能发生现象[^3]。为了完全杜绝的发生,在事务处理过程中可以考虑提升到更高的隔离级别——即 **串行化(Serializable)**。 在这种最高级别的隔离模式里,所有的查询都会被当作加锁操作执行,从而确保不会有任何其他会话能够插入新的记录或者修改现有符合条件的记录直到当前事务完成为止[^2]。 ```sql SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; START TRANSACTION; -- 执行一系列的操作... COMMIT; ``` #### 利用 Next-Key Locks 技术 除了调整隔离等级外,InnoDB 还采用了 next-key locks 的方式来增强对范围条件检索的支持。这种类型的锁定不仅涵盖了索引项本身还包括了一个间隙锁(gap lock),用于阻止其它交易在此区间内新增任何满足特定搜索条件的新条目,进而有效预防了幻影问题的产生[^1]。 #### 创建合适的索引来优化性能 适当设计表结构以及建立有效的索引同样有助于缓解因频繁发生而导致的应用层面上的问题。例如针对经常作为 WHERE 或 JOIN 条件字段创建唯一性约束或是复合索引等措施都可以显著降低实际业务场景下的风险。 ```sql CREATE UNIQUE INDEX idx_unique ON table_name(column_list); ALTER TABLE table_name ADD CONSTRAINT unique_constraint UNIQUE (column_list); ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值