🚀 优质资源分享 🚀
学习路线指引(点击解锁) | 知识定位 | 人群定位 |
---|---|---|
🧡 Python实战微信订餐小程序 🧡 | 进阶级 | 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。 |
💛Python量化交易实战💛 | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
一个事务具有
ACID
特性,也就是(Atomicity、Consistency、Isolation、Durability,即原子性
、一致性
、隔离性
、持久性
),本文主要讲解一下其中的Isolation
,也就是事务的隔离性
。
概述
四种隔离级别分别是:
读未提交(read uncommitted)
- 一个事务还没提交时,它修改的数据都可以被别的事物看到。
读已提交(read committed)
- 一个事务提交之后,它修改的数据才会被别的事物看到。
可重复读(repeatable read)
- 一个事务执行过程中看到的数据,总是和这个事务开启时看到的数据是一致的。在可重复读的隔离级别下,未提交的事务对其他事务也是不可见的。
串行化(serializable)
- 数据的
读
和写
都会加锁
,读
会加读锁
,写
会加写锁
。当遇到读写锁冲突时,后访问的事务必须等前一个事务执行完成后,再继续执行。
- 数据的
以上四种隔离级别,由上往下隔离强度越来越大,但是执行效率会随之降低。在设置隔离级别时候,需要在
隔离级别
和执行效率
两者做平衡取舍。
为了便于理解,下面就举一个例子:
在不同隔离级别下,事务A
会有哪些不同的返回结果,也就是图中的V1
、V2
、V3
的返回值分别是什么。
- 如果隔离级别是读未提交,
事务B
修改后数据无需提交事务,就能被事务A
读取,所以V1
、V2
、V3
的值都是2
。 - 如果隔离级别是读已提交,
事务B
修改后需要提交后,修改后的数据才能被事务A
读取,所以V1
的值是1
,事务B
提交,事务A
读取修改后的数据,所以V2
的值是2
,V3
的值也是2
。 - 如果隔离级别是可重复读,整个事务看到的事务和事务开启时看到的数据是一致的,开启看到的数据是
1
,所以V1
、V2
的值都是1
,事务A提交之后,获取到修改后的数据,所以V3
的值是2
。 - 如果隔离级别是串行化,会被锁住,此时事务B对应的线程处于阻塞状态,直到事务A提交之后,事务B才会继续
将1改成2
。所以V1
、V2
的值是1
,V3
的值是2
。
MySQL
默认的隔离级别是可重复读
。
隔离级问题
先了解几个基本概念:
脏读:事务A
修改数据,事务B
读取了数据后事务A
报错回滚,修改的数据没有提交到数据库中,此时事务B
读取修改的数据就是一个脏读,也就是一个事务读取到另一个事务未提交的数据就是脏读。
不可重复读:事务A
在同一个事务上多次读取同一个数据,在事务A
还没有结束时,事务B
修改了该数据,由于事务B
的修改,导致事务A
两次读取的数据不一致,就出现了不可以重复读的现象。
幻读:事务A
根据条件查询得到N
条数据,但此时事务B
更改或者增加了M
条符合事务A
查询的条件的数据。这样当事务A
再次查询的时候发现会有N + M
条数据,产生了幻读。
几种隔离级别可能会有脏读
、不可重复读
或者幻读
的问题,它们之间的关系如下:
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
读未提交 | √ | √ | √ |
读提交 | × | √ | √ |
可重复读 | × | × | √ |
串行化 | × | × | × |
读未提交
:可能会出现脏读
、不可重复读
、幻读
,读取未提交事务的数据,数据撤回了,就是一种脏读
。如果其他事务修改同一个数据,事务读取的数据也是不同的,所以也存在不可重复读
。同时也能读取到其他事务添加的数据,所以也存在幻读
。读已提交
:该隔离级别只能读取到其他事务提交后的数据,所以不存在脏读
。但是在第一次读取数据后,其他事务修改后数据并提交事务,此时事务读取到数据就和第一次读到的数据不一致了,也就存在不可重复读
。同时其他事务可以添加多条数据,也存在幻读
。可重复度读
:表示整个事务看到的事务和开启后的事务能看到的数据是一致的,既然数据是一致的,所以不存在不可重复读
。而且不会读取其他事务修改的数据,也就是不存在脏读
。而对同一个批
数据,可能会存在添加的情况,所以可能会存在幻读的情况。窜行化
:当发生读写锁冲突时,后面的事务要等前面的事务执行完毕之后再执行,所以一定是先读或者先写的执行完毕之后再执行后读或者写,读写按照顺序依次进行,所以不存在脏读
、不存在不可重复读
、也不存在幻读
。
隔离级别原理
隔离级别的主要是多版本并发控制MVCC
,MVCC
是通过保存数据在某个时间点的快照来实现的。
InnoDB
实现的MVCC
,是通过在每行记录后面保存两个隐藏列来实现,一个是保存行的创建时间,另一个是保存行的过期时间。当然存储的不是时间,而是系统版本号
。每开启一个新的事务,系统版本号先自动递增,该系统版本号会作为事务的版本号,用来和查询到的每行记录的版本号做比较。比如在可重复读
隔离级别下,MVCC
是如何操作的:
- SELECT
InnoDB
会根据以下两个条件检查每行记录:-
InnoDB
只查找版本号早于当前事务的数据行(系统版本号小于或者等于事务的系统版本号),这样可以确保事务读取的行,要么是在事务开始前就存在,要么是事务自身插入或者更新过。
-
- 行的删除版本要么未定义,要么大于当前事务版本号。这可以确保事务读取到的行,在事务开始之前未被删除。
-
- 只有符合上述两个条件的记录,才能返回作为查询的结果。
- INSERT
InnoDB
为新插入的每一行保存当前系统版本号作为行版本号。
- DELETE
InnoDB
为删除的每一行保存当前系统版本号作为行删除的标识。
- UPDATE
InnoDB
为插入一行新记录,保存当前系统版本号作为行版本号,同时保存当前系统版本号到原来的行作为行删除标识。
保存着两个额外的系统版本号,大多数读操作都可以不用加锁
。这样设计是的读数据的操作很简单,性能很好,并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间,需要做更多的行检查工作,以及一些额外的维护工作。
MVCC
只在读已提交
和可重复读
两个隔离级别下生效。其他两个隔离级别下MVCC都不能生效,因为读未提交
总是读取到最新的数据行,无需记录当前事务版本号。而串行化
会对所有的读写都会进行加锁,先读、先写
的先执行,后读
、后写
的后执行。也不需要记录记录版本号精心比对。
InnoDB
的行数据有多个版本,每个数据版本都有自己的row trx_id
,每个事务或者语句都有自己的一致性视图。查询语句是一致性读,一致性读会根据row trx_id
和一致性视图确定数据版本的可见性。
- 可重复读,只查询在事务启动前就提交完成的数据。
- 读已提交,只查询语句启动前其他事务提交的数据。
总结
-
四种隔离级别:
读未提交
:数据会读取其他事务未更新到数据的数据。可能会存在脏读
、不可重复读
、幻读
的问题。读已提交(read committed)
:数据只能读取其他事务提交的数据,不存在脏读
,但是可能会存在不可重复读
、幻读
的问题。可重复读(repeatable read)
:事务执行过程中看到的数据,总是和这个事务开启时看到的数据是一致的。在可重复读的隔离级别下,未提交的事务对其他事务也是不可见的。不存在脏读
、不可重复读
,但是可能会存在幻读
问题。串行化(serializable)
:存在读写锁
冲突时,后访问的事务会等前一个事务执行完毕后,再继续执行。
-
MySQL
采用了MVVC
(多版本并发控制)解决读已提交
、可重复读
隔离问题。- 执行一条
SQL
语句,都会保存两个隐藏的列。一个是保存创建时间,一个保存过期时间,储存的系统版本号
。 - 每次开启一个事务都会系统会递增一个
系统版本号
,作为事务的版本号。select
,查询早于当前事务的数据。insert
添加版本号。delete
为删除的行把版本号作为删除标识。update
,先插入一条数据,保存当前系统版本号。同时保存原来的行作为行删除标志。
- 执行一条