MySQL事务隔离级别： 在介绍脏读，不可重复读，幻读现象之前，我们先来了解MySQL的事务隔离级别，因为脏读，不可重复读，幻读等现象都是由数据库里的事务隔离级别来决定是否可能发生的。 由于第二个事务的修改，那么第一个事务读到的数据可能不一样，这样就发生了在一个事务内两次读到的数据是不一样的，因此称为不可重复读，即原始读取不可重复。 不可重复读现象主要是指，在一个事务结束前（执行commit或rollback前），进行两次或多次读取同一个数据会出现不同的结果，所以称为不可重复读，因为重复读取就会出现这种数据不一致的情况。 A在事务生命周期内多次查询数据时数据发生变化，才能算得上是不可重复读或幻读现象，如果用户A在一个事务结束后接着在另一个新的事务里查询后发现数据发生了变化，那么这就不算是不可重复读或者幻读。 不可重复读和幻读的区别： 不可重复读强调的是每次读取的是相同位置的数据，且该数据在另一个事务下被修改。注重的是修改。这个位置指的是哪一行、哪一个字段的数据。
2.1 何为脏读、不可重复读、幻读 脏读 所谓脏读是指一个事务中访问到了另外一个事务未提交的数据，如下图： ? 不可重复读 所谓不可重复读是指在一个事务内根据同一个条件对行记录进行多次查询，但是搜出来的结果却不一致。 发生不可重复读的原因是在多次搜索期间查询条件覆盖的数据被其他事务修改了，下面借助图表来解析下不可重复读。 ? 不可重复读的存在显得不是那么不可容忍，毕竟读取的是已经提交了的数据。 幻读 所谓幻读是指同一个事务内多次查询返回的结果集不一样（比如增加了或者减少了行记录）。 不同在于不可重复读是同一个记录的数据内容被修改了，幻读是数据行记录变多了或者少了： ?
提供包括云服务器，云数据库在内的90+款云计算产品。打造一站式的云产品试用服务，助力开发者和企业零门槛上云。
而由于一个事务在机器层面可能需要几条指令完成，这也意味着它在并发时会出现如下问题：脏读、不可重复读和幻读，下面以MySQL为例详细介绍在什么情况下可能会出现上述问题。 Read Committed(读已提交) 针对当前读，RC隔离级别保证对读取到的记录加锁（记录锁），存在不可重复读现象（在一个事务内，多次读取，会读取到不同的数据）。 实验-> 不可重复读现象 清除test数据 truncate table test; ? 我们发现session2中执行两次select * from test会出现不同的结果，这就是不可重复读现象。 Repeatable Read(可重复读) 这是MySQL默认隔离级别，解决不可重复读，但是还会出现存在幻读现象。
脏读、不可重复读、幻读 在现代关系型数据库中，事务机制是非常重要的，假如在多个事务并发操作数据库时，如果没有有效的机制进行避免就会导致出现脏读，不可重复读，幻读。 这种在同一个事务中，前后两次读取的数据不一致的现象就是不可重复读(Nonrepeatable Read)。 ? 幻读和不可重复读有些类似，但是幻读强调的是集合的增减，而不是单条数据的更新。 ? 只能防止第一类更新丢失，不能解决脏读，可重复读，幻读，所以很少应用于实际项目。 可以防止脏读和第一类更新丢失，但是不能解决可重复读和幻读的问题。 可重复读 可重复读(Repeatable Read)，MySQL默认的隔离级别。
脏读、幻读、不可重复读的概念 脏读 所谓脏读是指一个事务中访问到了另外一个事务未提交的数据，如下图： ? 不可重复读 一个事务读取同一条记录2次，得到的结果不一致： ? 由于在读取中间变更了数据，所以会话 1 事务查询期间的得到的结果就不一样了。 授权读取 也称为读提交（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。 可重复读取（Repeatable Read） 可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻读数据。这可以通过“共享读锁”和“排他写锁”实现。 尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
、Read committed 、Repeatable read (默认)、Serializable ，这四个级别中的后三个级别可以逐个解决脏读 、不可重复读 、幻读这几类问题 1. 即脏读。 2. 不可重复读: 对于两个事务T1和T2，T1读取了一个字段，然后T2更新了该字段并提交之后，T1再次提取同一个字段，值便不相等了。 重复读取的结果不一致的情况发生。 3. UNCOMMITTED级别不做演示，其隔离性最低，会出现脏读、不可重复读、幻读等所有情况。 无法避免重复读（一个事务读取到另一个事务已经提交的数据） REPEATABLE READ避免不可重复读的情况发生，下面来看演示： 1. 避免不可重复读（一个事务读取到另一个事务已经提交的数据） 2.
InnoDB 是如何解决幻读、不可重复读？ 如何解决不可重复读 上一篇文章，已经说明 InnoDB 是如何解决不可重复读的。 一个事务只在第一次 SELECT 的时候会获取一次 Read view，而后面所有的 SELECT都会复用这个 Read view，这样每次读到的就是一样的，就可重复读。 ? 可重复读 InnoDB 是如何解决幻读的？ 幻读场景 InnoDB 行锁方式 记录锁：针对单个行记录加锁 间隙锁：（Gap Locking）:可以帮助啊我们锁住一个范围（索引之间的空隙），但是不包括记录本身。 然后事务A重新进行条件范围的查询，就不会出现幻读的情况。 ?
，系统不可以读取到重复的数据，成为不可重复读。 不可重复读和幻读到底有什么区别呢？ 、不可重复读 、幻读 这几类问题。 不可重复读和脏读的区别是：脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。 幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。 4.
我在这里分享一篇关于 MySQL 的可重复读介绍，讲得挺好的，可以解决一些疑惑，链接在下方引用处。 幻读比起不可重复读更加侧重强调两次查询得到的行数不一样（多了或少了），或者行数一样但不是同一批（被替换了）。 而且，根据定义，SQL 标准的可重复读无法解决幻读问题。 但是，MySQL 的可重复读比 SQL 的可重复读的标准要更高，具体表现为：仅仅用 select 语句时幻读不会发生（这种情况简称 Phantom Reads），但是出现与写有关的操作时幻读会发生（这种情况简称 另外，从面试的角度来说，如果没有强调是 MySQL 的情况，可以忽略这些，只要按照 SQL 的关于幻读和可重复读的定义来回答即可。
、不可重复读 、幻读这几类问题。 隔离级别 脏读 不可重复读 幻读 读未提交(Read uncommitted) 可能 可能 可能 读已提交(Read committed) 不可能 可能 可能 可重复读(Repeatable read) 这种情况也叫不可重复读，允许幻读的发生，是oracle数据库的默认隔离级别。 3. Repeatable Read(重复读) mysql的默认级别。 整个事务过程中，对同一笔数据的读取结果是相同的，不管其他事务是否在对共享数据进行更新，也不管更新提交与否。避免了脏读、不可重复读和幻读的发生。 4. Serializable(序列化) 最高隔离级别。 如上图所示，t3时刻，事务A读取到了事务B累加5但是还未提交的a值，且在t3时刻，事务B回滚了，那么事务A基于t3时刻的查询所做的操作就会出现问题。 2.不可重复读 事务A前后读取到的数据不一致。
，此时，应该启用只读事务支持 6) 事务ACID四个属性； 原子性（atomicity）、一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。 Repeatable Read ------- MySQL 、InnoDB存储引擎 read committed:开启一个事务,读一个数据,而后再次读,这2次可能不一样的 , 因为在这2次读之间可能有其他事务更改这个数据,这也就是读提交, 每次读到的数据都是已经提交的(行级锁,不锁间隙)。 read repeatable:开启一个事务,读一个数据,而后再次读,这2次读的数据是一致的(行级锁且是锁间隙); 8) 不可重复读与幻读的区别: 不可重复读的重点是修改,同样的条件,你读取过的数据 幻读的重点在于新增或者删除,同样的条件,第 1 次和第 2 次读出来的记录总条数不一样。
in PGPossibleSerializableNot possibleNot possibleNot possibleNot possible 在事务行为方面Postgresql对比Mysql一个重要的差一点就在于 Phantom Read，在Mysql的RR级别下，幻读是可以出现的，下面构造一个场景来说明这个问题。 上述场景的差异：MYSQL发生了幻读，而PG会等待其他事务的行为进而作出不同的相应： 其他事务提交：为避免幻读直接回滚当前事务 其他事务回滚：正常提交 PG对于事务行为有更为苛刻的保证，使用回滚的方式避免幻读 ，MYSQL不会回滚事务所以在业务侧看起来更加易用但也更加容易让人混淆。 上述场景的差异：MYSQL发生了幻读，而PG会等待其他事务的行为进而作出不同的相应： 其他事务提交：为避免幻读直接回滚当前事务 其他事务回滚：正常提交 PG对于事务行为有更为苛刻的保证，使用回滚的方式避免幻读
会出现前后读取结果不一样的情况，但读取的是最新数据。 通过这样的机制，保证了快照读的可重复读，但读取到的数据很可能已经过期了。 RR 会锁等待，在RR隔离级别下，事务1的sql不仅会对该记录加X锁，还会对上下两个数据间隙加间隙锁，以此确保在数据读取期间，其它事物不会在该间隙内增加数据，从而保证可重复读。 ? 总结 RR隔离级别下，快照读通过undo log来保证可重复读，当前读通过X（S）锁+GAP锁来保证可重复读，但显然快照读和当前读之间无法保证可重复读。 本文对可重复读的实现机制做了阐述，关于undo log、锁等知识仅仅从简描述，后面有时间再详细写一下。 版权声明 本博客所有的原创文章，作者皆保留版权。
事物隔离级别是可重复度： section 1: （1）创建数据库： create DATABASE TESTDB; （2）创建表： CREATE TABLE `t` ( section 2: （1） beging; （2）更新数据：update t set c=0 where id=c; （3）commit; 事物的提交，因为行锁，section 1 做不了改行的操作 但是使用：select * from t for update; 可以获取更新的数据，这就是悲观锁了。 ? 还可以参考： https://blog.csdn.net/cweeyii/article/details/70991230
Hibernate中的事务隔离问题（脏读、不可重复读、幻读） 1.事务的特性 事务的四个特性： 1）原子性：事务是进行数据库操作的最小单位，所以组成事务的各种操作是不可分割的 2）一致性：组成事务的各种操作 这就导致A事务读到了错误的数据 2）不可重复读：一个事务读到了另一个事务已经提交的数据 如：A事务中有两次相同的读取数据a的操作，第一次对数据a进行了读操作之后，B事务修改了数据a并提交，那么在A事务第二次读取数据 a时，就得到了两个不同的结果 3）幻读：像发生了幻觉一样的操作 如：A事务在对一个表中的全部数据进行修改时，B事务向表中插入了一条新的数据，当A事务提交之后，你会发现还有一条数据（就是B事务新增的数据） 这就像发生了幻觉一样 3.事务的隔离级别 1） Serializable (串行化)：可避免脏读、不可重复读、幻读 2） Repeatable read (可重复读)：可避免脏读、不可重复读 3） Read committed (读已提交)：可避免脏读 4） Read uncommitted (读未提交)：最低级别，任何情况都无法保证
该级别解决了RC不可重复读的问题，但是存在幻读问题（幻读后面会详解）。 可以发现最新结果，已经是回滚后的数据。很显然：如果有脏读问题出现，就更加保证不了“可重复读”。 2.2 不可重复读 ? 将事务隔离级别设置成read committed（即：读已提交），可解决脏读问题，但满足不了“可重复读需求”。 2.4 串行化 从db层面，要想同时解决脏读、不可重复读、幻读，只有串行化这个级别可以做到。 小结： 隔离级别 存在的问题 读未提交 脏读、不可重复读、幻读 读已提交 不可重复读、幻读 可重复读 幻读 串行化 性能问题 隔离级别越严格，db综合性能越低。
不可重复读 表中的数据如下，设置隔离级别为提交读 ? ? 不可重复读是指在事务1内，读取了一个数据，事务1还没有结束时，事务2也访问了这个数据，修改了这个数据，并提交。紧接着，事务1又读这个数据。 由于事务2的修改，那么事务1两次读到的的数据可能是不一样的，因此称为是不可重复读。 当我们将当前会话的隔离级别设置为可重复读的时候，当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。 但是在可重复读的隔离级别上，会产生幻读的问题。 很多人容易搞混不可重复读和幻读，确实这两者有些相似。但不可重复读重点在于update和delete，而幻读的重点在于insert。 想用代码复现的，看原文，可以粘代码 推荐阅读： 深入浅出数据库事务 vim三种模式下的小技巧，提高一半工作效率 图解分布式系统架构演进之路 Java识堂 一个有干货的公众号 ?
事务可重复读采坑 1.1. 问题 今天碰到个事务幻读的情况，不容易啊，这不是事务间造成的问题，而是rpc调用产生的问题，实际上业务比较规范也不会出现这样的问题。 原因 通过select @@tx_isolation;查询mysql的事务隔离情况会发现，mysql默认是REPEATABLE-READ可重复读，映射到代码就是在一个事务内，用同样的条件查询数据库查询到的数据是相同的 ，哪怕别的系统在事务期间插入了数据，你也读不到 1.3. 解决办法 mysql使用这样的隔离级别是有道理的，避免重复读取的不准确，只要这个库都归一个系统管理，我们就可以避免我上述的问题 但既然我现在的遗留业务已经成为了这样的逻辑，在不能修改其它系统的前提下，我只能在代码上下功夫 总结 搞的这么复杂，实际上上面的改造在可以动其他系统的情况下，最简单就是获取订单信息不应该系统A来写sql读，既然系统B管理了订单表那么关于它的增删改查都由它提供就不会产生上述问题了
不可重复读 不可重复读是指一个事务先后执行同一条 SQL，但两次读取到的数据不同，就是不可重复读。 ，但存在不可重复读的问题。 不可重复读演示步骤2 在窗口 1 中开启事务，并给 Java 用户添加 20 元，但不提交事务，再观察窗口 2 中有没有脏读的问题，具体执行结果如下图所示： 从上述结果可以看出，当把窗口的事务隔离级别设置为读已提交 在同一个事务中，先后查询的两次结果不一致就是不可重复读。 不可重复读和脏读的区别 脏读可以读到其他事务中未提交的数据，而不可重复读是读取到了其他事务已经提交的数据，但前后两次读取的结果不同。 不可重复读和幻读的区别 二者描述的则重点不同，不可重复读描述的侧重点是修改操作，而幻读描述的侧重点是添加和删除操作。
简单理解一下可重复读 可重复读是指：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。 我们可以简单理解为：在可重复读隔离级别下，事务在启动的时候就”拍了个快照“。 在可重复读隔离级别下，一个事务在启动时，InnoDB 会为事务构造一个数组，用来保存这个事务启动瞬间，当前正在”活跃“的所有事务ID。”活跃“指的是，启动了但还没提交。 ： 若 trx_id 在数组中，表示这个版本在事务启动时还未提交，不可见； 若 trx_id 不在数组中，表示这个版本在事务启动时已经提交，可见。 ； 通过 undo log，找到上一个历史版本，trx_id=102，比高水位大，不可见； 继续找上一个历史版本，trx_id=90，比低水位小，可见。 可重复读的核心是一致性读，而事务更新数据的时候，只能使用当前读，如果当前记录的行锁被其他事务占用，就需要进入锁等待。 参考 03 | 事务隔离：为什么你改了我还看不见？
消息队列 TDMQ 是基于 Apache 顶级开源项目Pulsar自研的金融级分布式消息中间件，是一款具备跨城高一致、高可靠、高并发的分布式消息队列，拥有原生Java 、 C++、Python、GO 多种API， 支持 HTTP 协议方式接入，可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。
扫码关注云+社区
领取腾讯云代金券
云服务器
测试服务 WeTest
云数据库 PostgreSQL
文件存储
SSL 证书