幻读和不可重复读的个人理解和区分

本文解析了数据库中幻读与不可重复读的概念及区别,重点介绍了它们产生的原因及如何通过锁定机制来避免这两种现象。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

幻读和不可重复读常常让人感到疑惑和难以区分。以下,是个人对幻读和不可重复读的一些理解和区分。

首先两者官方概念如下,
不可重复读(non-repeatable read):在一个事务内,多次读同一个数据。在这个事务还没有结束时,另一个事务也访问该同一数据。那么,在第一个事务的两次读数据之间。由于第二个事务的修改,那么第一个事务读到的数据可能不一样,这样就发生了在一个事务内两次读到的数据是不一样的,因此称为不可重复读,即原始读取不可重复。

幻读(phantom read):幻读是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,比如这种修改涉及到表中的“全部数据行”。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入“一行新数据”。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样.一般解决幻读的方法是增加范围锁,锁定检索范围为只读,这样就避免了幻读。

那么从形成的原因来看,不可重复读大多由update,delete造成,而幻读一般由insert造成。

从控制的角度来看,避免不可重复读只要锁定where所对应的行(比如行锁),而避免幻读需要引入范围锁或者表锁。(比如innodb以间隙锁实现)

<think>嗯,用户这次的问题是关于数据库事务中脏不可重复区别。之前我已经解释过事务传播行为隔离级别的区别,现在用户想深入理解这些并发问题。用户引用了多篇关于数据库事务的文章,内容很专业。从引用[1][3][4][5]来看,用户主要关注三种现象的具体表现差异。特别是引用[5]强调与数据行数变化的关系,这点需要重点说明。用户可能正在学习数据库事务,或者遇到了实际的并发问题。ta特意要求区分这三个概念,说明之前可能混淆过它们。需要特别注意用生活化的类比帮助理解。脏最危险,就像偷看别人未提交的草稿。引用[1][3]都强调这是取未提交数据。不可重复更像是同一事务内数据"变脸",引用[3]用"两次查询不一致"描述得很准确。最特别,引用[5]指出关键在于"行数变化",就像魔术师凭空变出鸽子。 表格对比会很有用,但要注意引用[4]的隔离级别对照表不能直接复制,需要转化。隔离级别部分要简明,引用[2]提到"SERIALIZABLE_READ能解决所有问题"这点值得强调。最后用"文件草稿/合同金额/员工名单"的类比收尾,既呼应引用内容,又能让用户记住本质区别。相关问题的设计要延续事务主题,特别是隔离级别选择这种实用问题。</think>以下是数据库事务中脏不可重复的详细区别及对比: --- ### 一、核心概念对比 | **现象** | **本质问题** | **触发场景** | **示例** | |----------------|----------------------------|------------------------------------------|------------------------------------------| | **脏** | 取**未提交**的数据 | 事务A事务B**修改中但未提交**的数据 | 事务B修改金额未提交,事务A到错误金额[^1][^3] | | **不可重复** | 同数据**多次取结果不同** | 事务A两次取之间,事务B**修改并提交**了数据 | 事务A首次金额100,事务B改为200提交后,事务A第二次金额变为200[^1][^3] | | **** | 同查询**返回行数不同** | 事务A两次查询之间,事务B**新增/删除**了数据 | 事务A首次查10条记录,事务B新增1条提交后,事务A第二次查得11条记录[^3][^5] | > **关键区别**: > 脏关注**数据是否提交**,不可重复关注**数据值是否变化**,关注**数据行数是否变化**[^2][^5]。 --- ### 二、隔离级别的解决能力 | **隔离级别** | 脏 | 不可重复 | | |----------------------|------|------------|------| | **READ UNCOMMITTED** | ❌ | ❌ | ❌ | | **READ COMMITTED** | ✅ | ❌ | ❌ | | **REPEATABLE READ** | ✅ | ✅ | ❌* | | **SERIALIZABLE** | ✅ | ✅ | ✅ | > *注:MySQL的`REPEATABLE READ`通过间隙锁可避免,但标准SQL中仍可能存在[^3][^4]。 --- ### 三、技术原理与示例 #### 1. **脏** ```sql -- 事务A BEGIN; UPDATE accounts SET balance = 200 WHERE id = 1; -- 未提交 -- 事务B(READ UNCOMMITTED) BEGIN; SELECT balance FROM accounts WHERE id = 1; -- 到200(脏数据) ``` > 事务B取到事务A的**中间状态**,若事务A回滚,数据将不一致[^1][^3]。 #### 2. **不可重复** ```sql -- 事务A BEGIN; SELECT balance FROM accounts WHERE id = 1; -- 返回100 -- 事务B提交更新 UPDATE accounts SET balance = 200 WHERE id = 1; COMMIT; -- 事务A再次查询 SELECT balance FROM accounts WHERE id = 1; -- 返回200(值变化) ``` > 同一事务内**相同查询**结果不同,因其他事务修改了数据[^3][^5]。 #### 3. **** ```sql -- 事务A(查询年龄<30的用户) BEGIN; SELECT * FROM users WHERE age < 30; -- 返回10条 -- 事务B新增用户并提交 INSERT INTO users (name, age) VALUES ('Bob', 25); COMMIT; -- 事务A再次查询 SELECT * FROM users WHERE age < 30; -- 返回11条(行数变化) ``` > 重点在于**数据行数变化**(新增/删除),而非单行数据修改[^5]。 --- ### 四、解决方式 1. **提升隔离级别** - `READ COMMITTED` 解决脏 - `REPEATABLE READ` 解决不可重复 - `SERIALIZABLE` 彻底解决所有问题(但性能最低)[^2][^4] 2. **MySQL特殊优化** 通过**间隙锁**(Gap Lock)在`REPEATABLE READ`级别阻止,例如锁定`age < 30`的范围阻止新增[^4]。 --- ### 五、生活化类比 - **脏** 👉 偷看别人未保存的文档草稿 - **不可重复** 👉 两次查看合同时发现金额被修改 - **** 👉 两次统计员工名单时发现人数变化 > 三者本质都是**事务间可见性控制不足**导致的数据一致性问题[^1][^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值