mysql数据库隔离级别 如何查看mysql数据库隔离级别
这篇文章给大家聊聊关于mysql数据库隔离级别,以及如何查看mysql数据库隔离级别对应的知识点,希望对各位有所帮助,不要忘了收藏本站哦。
mysql有几种隔离级别
mysql有4种隔离级别,分别为:读未提交内容、读取提交内容、可重复读、可串行化。
Mysql的四种隔离级别
SQL标准定义了4类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的。低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销。【视频教程推荐:Mysql教程】
读未提交内容(read-uncommitted)
在该隔离级别中,所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少。
该隔离级别会出现的问题是:脏读(Dirty Read),即读取到了未提交的数据。
读取提交内容(read-committed)
这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。
该隔离级别会出现的问题是:不可重复读(Nonrepeatable Read),即不可重复读意味着我们在同一个事务中执行完全相同的select语句时可能看到不一样的结果。
导致这种情况的原因可能有:
1)、有一个交叉的事务有新的commit,导致了数据的改变;
2)、一个数据库被多个实例操作时,同一事务的其他实例在该实例处理其间可能会有新的commit
可重复读(repeatable-read)
这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。
不过理论上,这会导致另一个棘手的问题:幻读(Phantom Read)。
简单的说,幻读指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影”行。
InnoDB和Falcon存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control)机制解决了该问题。
可串行化(serializable)
这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。在这个级别,可能导致大量的超时现象和锁竞争。
在这个级别,可能导致大量的超时现象和锁竞争。
mysql隔离级别有几种
(推荐教程:mysql教程)
Mysql的四种隔离级别
SQL标准定义了4类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的。低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销。
1、Read Uncommitted(读取未提交内容)
在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少。读取未提交的数据,也被称之为脏读(Dirty Read)。
2、Read Committed(读取提交内容)
这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。
它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读(Nonrepeatable Read),因为同一事务的其他实例在该实例处理其间可能会有新的commit,所以同一select可能返回不同结果。
3、Repeatable Read(可重读)
这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。
不过理论上,这会导致另一个棘手的问题:幻读(Phantom Read)。简单的说,幻读指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影”行。
InnoDB和Falcon存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control)机制解决了该问题。
4、Serializable(可串行化)
这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。在这个级别,可能导致大量的超时现象和锁竞争。
问题
这四种隔离级别采取不同的锁类型来实现,若读取的是同一个数据的话,就容易发生问题。例如:
1、脏读(Drity Read):
某个事务已更新一份数据,另一个事务在此时读取了同一份数据,由于某些原因,前一个RollBack了操作,则后一个事务所读取的数据就会是不正确的。
2、不可重复读(Non-repeatable read):
在一个事务的两次查询之中数据不一致,这可能是两次查询过程中间插入了一个事务更新的原有的数据。
3、幻读(Phantom Read):
在一个事务的两次查询中数据笔数不一致,例如有一个事务查询了几列(Row)数据,而另一个事务却在此时插入了新的几列数据,先前的事务在接下来的查询中,就会发现有几列数据是它先前所没有的。
如何查看mysql数据库隔离级别
术式之后皆为逻辑,一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下,数据修改的顺序是固定的、可预期的结果,但是并发执行的情况下,数据的修改是不可预期的,也不固定,为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果,由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的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类型的优化锁)
粒度加载的安全&性能(如获取行锁前,先获取页锁,页锁在执行获取行锁操作后即释放,无论是否获取成功)等多个层次去思考并发这玩意。
mysql数据库隔离级别的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于如何查看mysql数据库隔离级别、mysql数据库隔离级别的信息别忘了在本站进行查找哦。