oracle如何支持幻读 oracle如何解决幻读

oracle的Read Committed何时会出现非重复读和幻像

1、幻想读：事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。

专注于为中小企业提供网站设计制作、成都做网站服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业紫阳免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了近千家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

2、不可重复读取：事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读。

3、脏读：事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就无效，也就是脏数据。

为了处理这些问题，SQL标准定义了以下几种事务隔离级别

READ UNCOMMITTED 幻想读、不可重复读和脏读都允许。

READ COMMITTED 允许幻想读、不可重复读，不允许脏读

REPEATABLE READ 允许幻想读，不允许不可重复读和脏读

SERIALIZABLE 幻想读、不可重复读和脏读都不允许

Oracle数据库支持READ COMMITTED 和 SERIALIZABLE这两种事务隔离级别（Oracle还提供了自己独有的事务隔离级别：read only ；default READ COMMITTED（最低级别））。

1.3 REPEATABLE READ（可重复读）

1.设置为可重复读

SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;

2.首先TB做出一次查询，此时name为bb

3.TA对数据进行修改，并提交

4.此时加入session C作为对比，使用自动事务并做出查询，可见数据已经被修改

5.在已经开启事务的TB中，查询到的，仍然是数据开启事务之前的状态，所以数据是可重复读的

可重复读隔离级别中，每当事务开始后，第一次执行sql语句时（或者执行START TRANSACTION WITH CONSISTENT SNAPSHOT）MVCC会建立一个read view，选取当时的系统版本号，作为事务版本号，以Undo log的行系统版本号与事务版本号进行对比，增删改查都要遵循如下模式：

SELECT：

1, InnoDB只查找版本早于当前事务版本的数据行(行的系统版本号小于等于事务版本号)，这样可以确保事务读取的行，要么是事务开始前就存在的，要么是事务自身插入的或修改过的。

2, 行的删除号要么未定义，要么大于当前事务版本号，这样可以确保事务读取到的行，在事务开始之前未被删除。

INSERT：

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

DELETE：

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

UPDATE：

InnoDB 为插入的每一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

所以READ COMMITTED和REPEATABLE READ的区别在于，READ COMMITTED总是读取被锁定行的最新一份快照数据， 所以会有不可重复读的问题。而REPEATABLE READ读取事务开始时行系统版本号小于事务版本号的数据，解决不可重复读的问题。

此外要提的一点是，MySql的REPEATABLE READ与Oracle的不同，不但解决了不可重复读问题，还解决的“幻读”问题。

幻读的产生：遵循上述增删改查模式，假设TA事务的事物版本号为3，TB早于TA开启事务，TB事物版本号为2，TB先新增一条数据，行数据的版本号为2，并提交。TB提交后，TA查询时，满足“行的系统版本号小于等于事务版本号”的条件，可以查到数据，形成“幻读”。

InnoDB采用Next-key Lock(间隙锁)来避免“幻读”问题。

Record Lock：单个行记录的锁，锁定的是索引而非记录本身。

GAP Lock：间隙锁，锁定一个范围，但不包含记录本身。

Next-Key Lock：Gap Lock+Record Lock 锁定一个范围并锁定记录本身。

举例说明：

某表字段为ID和NAME，有3条睡觉，ID分别为10，20，50。

如果索引为 10，20，50，那么：

Record Lock：select * from tab where id = 10 for update; //对id=10单行进行加锁

Gap Lock锁范围：（-∞，10）（10，20）（20，50）（50，+∞）

Next-Key Lock锁范围：（-∞，10] （10，20] （20，50] （50，+∞）

当查询的索引含有唯一属性时，InnoDB会对Next-Key Lock进行优化，将其降级为Record Lock，即仅锁住索引本身，而不是范围。

虽然避免了幻读问题，但是还有个特殊情况，感觉可以叫做“幻改”，即当前事务修改了本身并不能查询到的数据。这也是MVCC造成的假象，当前事务虽然查询不到其他事务提交的数据，但是可以对其他事务提交的数据进行修改。

MySQL 事务的默认隔离级别是什么？可以解决幻读问题么？

我们设想一个场景，这个场景中我们需要插入多条相关联的数据到数据库，不幸的是，这个过程可能会遇到下面这些问题：

上面的任何一个问题都可能会导致数据的不一致性。为了保证数据的一致性，系统必须能够处理这些问题。事务就是我们抽象出来简化这些问题的首选机制。事务的概念起源于数据库，目前，已经成为一个比较广泛的概念。

何为事务？ 一言蔽之， 事务是逻辑上的一组操作，要么都执行，要么都不执行。

事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 1000 元，这个转账会涉及到两个关键操作，这两个操作必须都成功或者都失败。

事务会把这两个操作就可以看成逻辑上的一个整体，这个整体包含的操作要么都成功，要么都要失败。这样就不会出现小明余额减少而小红的余额却并没有增加的情况。

大多数情况下，我们在谈论事务的时候，如果没有特指 分布式事务 ，往往指的就是 数据库事务 。

数据库事务在我们日常开发中接触的最多了。如果你的项目属于单体架构的话，你接触到的往往就是数据库事务了。

那数据库事务有什么作用呢？

简单来说，数据库事务可以保证多个对数据库的操作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循： 要么全部执行成功,要么全部不执行 。

另外，关系型数据库（例如： MySQL 、 SQL Server 、 Oracle 等）事务都有 ACID 特性：

ACID

这里要额外补充一点： 只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！

在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对同一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。

不可重复读和幻读区别 ：不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次查询同一条查询语句（DQL）时，记录发现记录增多或减少了。

SQL 标准定义了四个隔离级别：

隔离级别脏读不可重复读幻读 READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE

MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。

SERIALIZABLE 隔离级别，是通过锁来实现的。除了 SERIALIZABLE 隔离级别，其他的隔离级别都是基于 MVCC 实现。

不过， SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读） 。我们可以通过 SELECT @@tx_isolation; 命令来查看，MySQL 8.0 该命令改为 SELECT @@transaction_isolation;

从上面对 SQL 标准定义了四个隔离级别的介绍可以看出，标准的 SQL 隔离级别定义里，REPEATABLE-READ(可重复读)是不可以防止幻读的。

但是！InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，主要有下面两种情况：

因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 READ-COMMITTED ，但是你要知道的是 InnoDB 存储引擎默认使用 REPEATABLE-READ 并不会有任何性能损失。

InnoDB 存储引擎在分布式事务的情况下一般会用到 SERIALIZABLE 隔离级别。

什么是oracle数据库隔离级别

1.查看当前会话隔离级别

select @@tx_isolation;

2.查看系统当前隔离级别

select @@global.tx_isolation;

3.设置当前会话隔离级别

set session transaction isolatin level repeatable read;

4.设置系统当前隔离级别

set global transaction isolation level repeatable read;

5.命令行，开始事务时

set autocommit=off 或者 start transaction

关于隔离级别的理解

1.read uncommitted

可以看到未提交的数据（脏读），举个例子：别人说的话你都相信了，但是可能他只是说说，并不实际做。

2.read committed

读取提交的数据。但是，可能多次读取的数据结果不一致（不可重复读，幻读）。用读写的观点就是：读取的行数据，可以写。

3.repeatable read(MySQL默认隔离级别)

可以重复读取，但有幻读。读写观点：读取的数据行不可写，但是可以往表中新增数据。在MySQL中，其他事务新增的数据，看不到，不会产生幻读。采用多版本并发控制（MVCC）机制解决幻读问题。

4.serializable

可读，不可写。像java中的锁，写数据必须等待另一个事务结束。

数据库哪个隔离级别可以实现脏读

对于同时运行的多个事务, 当这些事务访问数据库中相同的数据时, 如果没有采取必要的隔离机制, 就会导致各种并发问题:

• 脏读: 对于两个事物 T1, T2, T1 读取了已经被 T2 更新但还没有被提交的字段. 之后, 若 T2 回滚, T1读取的内容就是临时且无效的.

• 不可重复读: 对于两个事物 T1, T2, T1 读取了一个字段, 然后 T2 更新了该字段. 之后, T1再次读取同一个字段, 值就不同了.

• 幻读: 对于两个事物 T1, T2, T1 从一个表中读取了一个字段, 然后 T2 在该表中插入了一些新的行. 之后, 如果 T1 再次读取同一个表, 就会多出几行.

数据库事务的隔离性: 数据库系统必须具有隔离并发运行各个事务的能力, 使它们不会相互影响, 避免各种并发问题.

一个事务与其他事务隔离的程度称为隔离级别. 数据库规定了多种事务隔离级别, 不同隔离级别对应不同的干扰程度, 隔离级别越高, 数据一致性就越好, 但并发性越弱

数据库提供了4中隔离级别：

隔离级别 描述

READ UNCOMMITTED(读未提交数据) 允许事务读取未被其他事务提交的变更，脏读、不可重复读和幻读的问题都会出现

READ COMMITED(读已提交数据) 只允许事务读取已经被其他事务提交的变更，可以避免脏读，但不可重复读和幻读问题仍然会出现

REPEATABLE READ(可重复读) 确保事务可以多次从一个字段中读取相同的值，在这个事务持续期间，禁止其他事务对这个字段进行更新，可以避免脏读和不可重复读，但幻读的问题依然存在

SERIALIZABLE(串行化) 确保事务可以从一个表中读取相同的行，在这个事务持续期间，禁止其他事务对该表执行插入、更新和删除操作，所有并发问题都可以避免，但性能十分低

Oracle 支持的 2 种事务隔离级别：READ COMMITED, SERIALIZABLE. Oracle 默认的事务隔离级别为: READ COMMITED

Mysql 支持 4 中事务隔离级别. Mysql 默认的事务隔离级别为: REPEATABLE READ

oracle默认事务级别可导致重复读吗

事务的隔离级别

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。

√: 可能出现 ×: 不会出现

脏读不可重复读幻读

Read uncommitted√√√

Read committed×√√

Repeatable read××√

Serializable×××

注意：我们讨论隔离级别的场景，主要是在多个事务并发的情况下，因此，接下来的讲解都围绕事务并发。

Read uncommitted 读未提交

公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而 singo正好去查看账户，发现工资已经到账，是5000元整，非常高兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速 回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有2000元，singo空欢喜一场。

出现上述情况，即我们所说的脏读，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。

当隔离级别设置为Read uncommitted时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。

Read committed 读提交

singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好 在网上转账，把singo工资卡的2000元转到另一账户，并在singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有 钱，扣款失败，singo十分纳闷，明明卡里有钱，为何......

出现上述情况，即我们所说的不可重复读，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。

当隔离级别设置为Read committed时，避免了脏读，但是可能会造成不可重复读。

大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。

Repeatable read 重复读

当隔离级别设置为Repeatable read时，可以避免不可重复读。当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。

虽然Repeatable read避免了不可重复读，但还有可能出现幻读。

singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费 记录。有一天，她正在查询到singo当月信用卡的总消费金额（select sum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction ... ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出 现了幻觉，幻读就这样产生了。

注：Mysql的默认隔离级别就是Repeatable read。

Serializable 序列化

Serializable是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻像读。