mysql默认事务隔离级别

mysql默认事务隔离级别,第1张

SQL标准中支持4种事务隔离级别,READ_UNCOMMITTED(读未提交),READ_COMMITTED(读已提交),REPEATABLE_READ(可重复读),SERIALIZABLE(串行读),MySQL innodb引擎支持全部这4种事务隔离级别。

工具/原料:

联想Y7000P

Windows10

MySQL60

1、启动命令行窗口,连接MySQL数据

图示,通过MySQL提供的客户端命令mysql连接MySQL数据库。

2、通过系统变量查询数据库当前事务隔离级别

图示,通过查询数据库提供的系统变量 tx_isolation 或 transaction_isolation 的值即可获取当前的事务隔离级别。MySQL数据库默认的事务隔离级别是REPEATABLE_READ (可重复读)。

3、设置本次会话的事务隔离级别

图示,通过命令set session transaction isolation level可以设置本次会话的事务隔离级别,该设置不会影响其他会话,并且设置会随着当前会话的结束而结束。

4、设置全局会话的事务隔离级别

图示,通过命令set global transaction isolation level可以设置全局会话的事务隔离级别,该设置不会影响当前已经连接的会话,设置完毕后,新打开的会话,将使用新设置的事务隔离级别。

5、设置一次 *** 作的事务隔离级别

图示,通过命令set transaction isolation level可设置下一次事务 *** 作的隔离级别,该设置会随着下一次事务的提交而失效。

术式之后皆为逻辑,一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。

隔离级别的产生

在串型执行的条件下,数据修改的顺序是固定的、可预期的结果,但是并发执行的情况下,数据的修改是不可预期的,也不固定,为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果,由此产生了隔离级别。

所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。

事务的4种隔离级别

READ UNCOMMITTED       未提交读,可以读取未提交的数据。READ COMMITTED         已提交读,对于锁定读(select with for update 或者 for share)、update 和 delete 语句,                       InnoDB 仅锁定索引记录,而不锁定它们之间的间隙,因此允许在锁定的记录旁边自由插入新记录。                       Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ        可重复读,事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE           序列化

在了解了 4 种隔离级别的需求后,在采用锁控制隔离级别的基础上,我们需要了解加锁的对象(数据本身&间隙),以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围(不加锁);

SQL 语句根据条件扫描到的可能需要加锁的数据范围;

以单个数据范围为例,数据范围全集包含:(数据范围不一定是连续的值,也可能是间隔的值组成)

1 数据已经填充了整个数据范围:(被完全填充的数据范围,不存在数据间隙)

整形,对值具有唯一约束条件的数据范围 1~5 ,

已有数据1、2、3、4、5,此时数据范围已被完全填充;

整形,对值具有唯一约束条件的数据范围 1 和 5 ,

已有数据1、5,此时数据范围已被完全填充;

2 数据填充了部分数据范围:(未被完全填充的数据范围,是存在数据间隙)

整形的数据范围 1~5 ,

已有数据 1、2、3、4、5,但是因为没有唯一约束,

所以数据范围可以继续被 1~5 的数据重复填充;

整形,具有唯一约束条件的数据范围 1~5 ,

已有数据 2,5,此时数据范围未被完全填充,还可以填充 1、3、4 ;

3 数据范围内没有任何数据(存在间隙)

如下:

整形的数据范围 1~5 ,数据范围内当前没有任何数据。

在了解了数据全集的组成后,我们再来看看事务并发时,会带来的问题。

无控制的并发所带来的问题

并发事务如果不加以控制的话会带来一些问题,主要包括以下几种情况。

1 范围内已有数据更改导致的:

更新丢失:当多个事务选择了同一行,然后基于最初选定的值更新该行时,

由于每个事物不知道其他事务的存在,最后的更新就会覆盖其他事务所做的更新;

脏读: 一个事务正在对一条记录做修改,这个事务完成并提交前,这条记录就处于不一致状态。

这时,另外一个事务也来读取同一条记录,如果不加控制,

第二个事务读取了这些“脏”数据,并据此做了进一步的处理,就会产生提交的数据依赖关系。

这种现象就叫“脏读”。

2 范围内数据量发生了变化导致:

不可重复读:一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,

却发现其读出的数据已经发生了改变,或者某些记录已经被删除了。

这种现象就叫“不可重复读”。

幻读:一个事务按相同的查询条件重新读取以前检索过的数据,

却发现其他事务插入了满足其查询条件的新数据,这种现象称为“幻读”。

可以简单的认为满足条件的数据量变化了。

因为无控制的并发会带来一系列的问题,这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发,以实现我们所期望的结果(隔离级别)。

MySQL 隔离级别的实现

InnoDB 通过加锁的策略来支持这些隔离级别。

行锁包含:

Record Locks

索引记录锁,索引记录锁始终锁定索引记录,即使表中未定义索引,

这种情况下,InnoDB 创建一个隐藏的聚簇索引,并使用该索引进行记录锁定。

Gap Locks

间隙锁是索引记录之间的间隙上的锁,或者对第一条记录之前或者最后一条记录之后的锁。

间隙锁是性能和并发之间权衡的一部分。

对于无间隙的数据范围不需要间隙锁,因为没有间隙。

Next-Key Locks

索引记录上的记录锁和索引记录之前的 gap lock 的组合。

假设索引包含 10、11、13 和 20。

可能的next-key locks包括以下间隔,其中圆括号表示不包含间隔端点,方括号表示包含端点:

(负无穷大, 10]    (10, 11]    (11, 13]    (13, 20]    (20, 正无穷大)        对于最后一个间隔,next-key将会锁定索引中最大值的上方,

左右滑动进行查看

"上确界"伪记录的值高于索引中任何实际值。

上确界不是一个真正的索引记录,因此,实际上,这个 next-key 只锁定最大索引值之后的间隙。

基于此,当获取的数据范围中,数据已填充了所有的数据范围,那么此时是不存在间隙的,也就不需要 gap lock。

对于数据范围内存在间隙的,需要根据隔离级别确认是否对间隙加锁。

默认的 REPEATABLE READ 隔离级别,为了保证可重复读,除了对数据本身加锁以外,还需要对数据间隙加锁。

READ COMMITTED 已提交读,不匹配行的记录锁在 MySQL 评估了 where 条件后释放。

对于 update 语句,InnoDB 执行 "semi-consistent" 读取,这样它会将最新提交的版本返回到 MySQL,

以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。

总结&延展:

唯一索引存在唯一约束,所以变更后的数据若违反了唯一约束的原则,则会失败。

当 where 条件使用二级索引筛选数据时,会对二级索引命中的条目和对应的聚簇索引都加锁;所以其他事务变更命中加锁的聚簇索引时,都会等待锁。

行锁的增加是一行一行增加的,所以可能导致并发情况下死锁的发生。

例如,

在 session A 对符合条件的某聚簇索引加锁时,可能 session B 已持有该聚簇索引的 Record Locks,而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。

session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。

session A 通过索引 idA,session B通过索引 idB 。

当 where 条件获取的数据无间隙时,无论隔离级别为 rc 或 rr,都不会存在间隙锁。

比如通过唯一索引获取到了已完全填充的数据范围,此时不需要间隙锁。

间隙锁的目的在于阻止数据插入间隙,所以无论是通过 insert 或 update 变更导致的间隙内数据的存在,都会被阻止。

rc 隔离级别模式下,查询和索引扫描将禁用 gap locking,此时 gap locking 仅用于外键约束检查和重复键检查(主要是唯一性检查)。

rr 模式下,为了防止幻读,会加上 Gap Locks。

事务中,SQL 开始则加锁,事务结束才释放锁。

就锁类型而言,应该有优化锁,锁升级等,例如rr模式未使用索引查询的情况下,是否可以直接升级为表锁。

就锁的应用场景而言,在回放场景中,如果确定事务可并发,则可以考虑不加锁,加快回放速度。

锁只是并发控制的一种粒度,只是一个很小的部分:

从不同场景下是否需要控制并发,(已知无交集且有序的数据的变更,MySQL 的 MTS 相同前置事务的多事务并发回放)

并发控制的粒度,(锁是一种逻辑粒度,可能还存在物理层和其他逻辑粒度或方式)

相同粒度下的优化,(锁本身存在优化,如IX、IS类型的优化锁)

粒度加载的安全&性能(如获取行锁前,先获取页锁,页锁在执行获取行锁 *** 作后即释放,无论是否获取成功)等多个层次去思考并发这玩意。

事务隔离级别可以理解为锁定正在被某个事务所占用的资源以减少其他事务对这些数据库资源的影响,保证数据的一致性。在多用户系统中,经常出现多个事务同时需要 *** 作某一个数据库中的数据的情况,为了防止事务之间的相互影响,提高数据库数据的安全性和完整性,数据库系统提供了隔离机制。

隔离级别就是一个事务必须和其他事务隔离的程度,包括未提交读(ReadUncommitted)、提交读(ReadCommitted)、可重复读(RepeatableRead)、可串行化(Serializable)四个级别。

1未提交读未提交读是最低的事务隔离,仅保证不读取物理损坏的数据。

2提交读提交读比未提交读隔离级别更高一层,提交读隔离级别是大多数主流数据库的默认隔离级别,其保证了一个事务不会读到另一个并行事务已修改但未提交的数据,避免了“脏读取”的情况发生。

3可重复读可重复读保证了任何情况下,在同一个事务中前后数次所读取的数据是一致的,避免了“不可重复读取”的情况发生,是关系型数据库管理系统(MySQL)的默认隔离级别。

4可串行化可串行化是最高的事务隔离等级,是将数据库中所有事务以串联的方式连接起来,防止一个事务影响其他事务。在此隔离级别,将没有并发事务。

修改方法

有两种方法可以对配置了 systemd 的程序进行资源隔离:1 命令行修改:通过执行 systemctl set-property 命令实现,形式为 systemctl set-property name parameter=value;修改默认即时生效。2 手工修改文件:直接编辑程序的 systemd unit file 文件,完成之后需手工执行 systemctl daemon-reload 更新配置,并重启服务 systemctl restart nameservice。

systemd unit file 里支持的资源隔离配置项,如常见的:

CPUQuota=value

该参数表示服务可以获取的最大 CPU 时间,value 为百分数形式,高于 100% 表示可使用 1 核以上的 CPU。与 cgroup cpu 控制器 cpucfs_quota_us 配置项对应。

MemoryLimit=value

该参数表示服务可以使用的最大内存量,value 可以使用 K, M, G, T 等后缀表示值的大小。与 cgroup memory 控制器 memorylimit_in_bytes 配置项对应。

事务的4种隔离级别

READ UNCOMMITTED       未提交读,可以读取未提交的数据。

READ COMMITTED         已提交读,对于锁定读(select with for update 或者 for share)、update 和 delete 语句,InnoDB 仅锁定索引记录,而不锁定它们之间的间隙,因此允许在锁定的记录旁边自由插入新记录。                    

Gap locking 仅用于外键约束检查和重复键检查。

REPEATABLE READ        可重复读,事务中的一致性读取读取的是事务第一次读取所建立的快照。

SERIALIZABLE           序列化在了解了 4 种隔离级别的需求后,在采用锁控制隔离级别的基础上,我们需要了解加锁的对象(数据本身&间隙),以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围(不加锁);

SQL 语句根据条件扫描到的可能需要加锁的数据范围;

以单个数据范围为例,数据范围全集包含:(数据范围不一定是连续的值,也可能是间隔的值组成)

spring的事务处理主要是依靠AOP实现的,这个没什么好说的随便搜索一下,网上很多示例。

隔离级别是针对并发事务而言的,单个事务的处理很简单不多说。并发事务的处理则比较复杂,因为往往一条数据是跨事务的,这会造成许多不可预知的后果。

一般来说,系统执行并发事务时,会把当前在执行的事务独立起来,也就是和其他事务进行隔离。好像系统中只有这一个事务,其他事务不存在一样。这也就是完全隔离,即系统中只运行单位时间内,最多只有一个事务在执行,其他事务要等到该事务执行完毕之后才能执行,这在现实中基本是不可行的,比如,你要更新你的QQ用户信息,那么就是说,在你更新的这段时间内,其他的用户是无法更新他的用户信息的。

举个深动的例子,把事务比作一条在公路上奔跑的汽车,完全隔离,就像是,在汽车从公路一头到另一头这段时间内,公路上不允许有其他的汽车,这样做当然可以完全避免车祸,也就是数据跨事务带来的隐患风险,但是带来了巨大的效率问题,那么如果同时在公路上让多辆汽车行驶会造成什么情况呢。

具体来说有一下几种:

更新丢失(Lost Update):两个事务都企图去更新一行数据,导致事务抛出异常退出,两个事务的更新都白费了。

脏数据(Dirty Read):如果第二个应用程序使用了第一个应用程序修改过的数据,而这个数据处于未提交状态,这时就会发生脏读。第一个应用程序随后可能会请求回滚被修改的数据,从而导致第二个事务使用的数据被损坏,即所谓的“变脏”。

不可重读(Unrepeatable Read):一个事务两次读同一行数据,可是这两次读到的数据不一样,就叫不可重读。如果一个事务在提交数据之前,另一个事务可以修改和删除这些数据,就会发生不可重读。

幻读(Phantom Read):一个事务执行了两次查询,发现第二次查询结果比第一次查询多出了一行,这可能是因为另一个事务在这两次查询之间插入了新行。

以上就是并行事务处理时常遇到的大致问题。针对这些问题,提出了几个不同的事务隔离级别,适应特定的环境需要。

具体是:

读 *** 作未提交(Read Uncommitted):说明一个事务在提交前,其变化对于其他事务来说是可见的。这样脏读、不可重读和幻读都是允许的。当一个事务已经写入一行数据但未提交,其他事务都不能再写入此行数据;但是,任何事务都可以读任何数据。这个隔离级别使用排写锁实现。

读 *** 作已提交(Read Committed):读取未提交的数据是不允许的,它使用临时的共读锁和排写锁实现。这种隔离级别不允许脏读,但不可重读和幻读是允许的。

可重读(Repeatable Read):说明事务保证能够再次读取相同的数据而不会失败。此隔离级别不允许脏读和不可重读,但幻读会出现。

可串行化(Serializable):提供最严格的事务隔离。这个隔离级别不允许事务并行执行,只允许串行执行。这样,脏读、不可重读或幻读都可发生。

数据库系统。

事务的隔离级别是通过锁的机制实现的,事务的隔离级别是数据库开发商根据业务逻辑的实际需要定义的一组锁的使用策略。

事务有四种隔离级别是由低到高分别为Readuncommitted、Readcommitted、Repeatableread、Serializable。

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

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

何为事务? 一言蔽之, 事务是逻辑上的一组 *** 作,要么都执行,要么都不执行。

事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 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 80 该命令改为 SELECT @@transaction_isolation;

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

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

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

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

以上就是关于mysql默认事务隔离级别全部的内容,包括:mysql默认事务隔离级别、数据库事务隔离级别 一般用哪个、事务隔离级别分什么程度等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/9495338.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-28
下一篇2023-04-28

发表评论

登录后才能评论

评论列表(0条)

    保存