文章目录
我们的数据库一般都会并发执行多个事务,多个事务可能会并发的对相同的一批数据进行增删改查操作,可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。mysql
中可以通过begin
、commit
等命令开始或者提交一个事务,在使用Spring
的@Transitional注解
管理事务时,其底层也是使用Aop
调用mysql
的begin
、commit
等命令来解决的。
Mysql默认的事务隔离级别是可重复读,用Spring开发程序时,如果不设置隔离级别默认用Mysql设置的隔离级别,如果Spring设置了就用spring设置的隔离级别
1. 事务及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元,具有以下4个属性,通常简称为事务的ACID属性。
- 原子性(Atomicity) :事务是一个原子操作,一组事务中的增删改查,要么全都执行成功,要么全都执行失败。在代码中就表现为
@Transitional注解
包裹住的代码是一个原子操作 - 一致性(Consistent):类似于原子性的概念,不过是针对于数据层面。要求在事务开始和完成时,数据都必须保持一致状态。
- 隔离性(Isolation):数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的。比如A事务读到数据为10,B事务修改数据为5,那么隔离性要求A事务看不到B事务的修改,仍然认为数据是10,继续执行。否则A事务无法读取一个确定的数据,代码就会很混乱,可重复度隔离级别实现了隔离性
- 持久性(Durable) :事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。
2. 事务并发带来的问题
- 脏写
- 当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。
- 脏读
- 事务
A
读取到了事务B
已经修改但尚未提交的数据,还在这个数据基础上做了操作。此时,如果B
事务回滚,A
读取的数据变得无效,属于脏数据,A
事务后续的操作其实是在操作虚假数据!不符合事务的一致性要求
- 事务
- 不可重复读
- 事务
A
内部的相同查询语句在不同时刻读出的结果不一致。一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,却发现其读出的数据已经发生了改变、或某些记录已经被删除了!这种现象就叫做“不可重复读”。不符合事务的隔离性
- 事务
- 幻读
- 事务
A
读取到了事务B
提交的新增数据,不符合隔离性 。一个事务按相同的查询条件重新读取以前检索过的数据,却发现其他事务插入了满足其查询条件的新数据,这种现象就称为“幻读”。不符合事务的隔离性
- 事务
这些问题的本质都是数据库的多事务并发问题,为了解决多事务并发问题,数据库设计了事务隔离级别
、锁机制
、MVCC多版本并发控制隔离机制
,用一整套机制来解决多事务并发问题。接下来逐个解析
3. 事务隔离级别
事务的隔离级别分为以下几种
- 查看当前数据库的事务隔离级别:
show variables like 'tx_isolation';
- 设置事务隔离级别:
set tx_isolation='REPEATABLE-READ';
数据库的事务隔离越严格,并发带来的问题就越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。所以Mysql
为了并发和性能的均衡,默认选择的事务隔离级别是可重复读。下面通过模拟并发来看一下各种隔离级别的作用
先创建一个表account
//创建表account
CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`balance` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lilei', '450');
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('hanmei', '16000');
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lucy', '2400');
①:读未提交
-
打开一个客户端A,并设置当前事务模式为read uncommitted(读未提交)
set tx_isolation='read-uncommitted';
,查询表account的初始值:客户端A:
-
在客户端A的事务提交之前,打开另一个客户端B,更新表account:
客户端B:
-
这时,虽然客户端B的事务还没提交,但是客户端A就可以查询到B已经更新的数据:
客户端A:
-
一旦客户端B的事务因为某种原因回滚,所有的操作都将会被撤销,那客户端A查询到的数据其实就是脏数据:
客户端B回滚:
-
在客户端A执行更新语句
update account set balance = balance - 50 where id = 1
,lilei
的balance
没有变成350,居然是400
这是什么原因呢?set balance = balance - 50
中的balance
是数据库中真实的值450
。如果使用java代码400-50=350
,那这样的话,客户端A打印的就是350
了,所以使用set balance = balance - 50
这种数据库级别的修改代替java代码,可保证修改操作的正确性!
②:读已提交
-
打开一个客户端
A
,并设置当前事务模式为read committed(未提交读)set tx_isolation='read-committed';
,查询表account的所有记录:
-
在客户端
A
的事务提交之前,打开另一个客户端B
,更新表account:
-
这时,客户端
B
的事务还没提交,客户端A
不能查询到B
已经更新的数据,解决了脏读问题:
-
客户端
B
的事务提交
-
客户端
A
执行与上一步相同的查询,结果 与上一步不一致,即产生了不可重复读的问题
③:可重复读
- 打开一个客户端
A
,并设置当前事务模式为repeatable read(可重复读)set tx_isolation='repeatable-read';
,查询表account的所有记录
- 在客户端
A
的事务提交之前,打开另一个客户端B
,更新表account中lilei
的balance
为350
,并提交
- 在客户端
A
查询表account的所有记录,与步骤(1)查询结果一致,没有出现不可重复读的问题
- 在客户端A,接着执行
update account set balance = balance - 50 where id = 1
,balance
直接变成300
,因为这里的balacne
使用的是,数据库真实的值。数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC(multi-version concurrency control)
机制,select
操作不会更新版本号,是快照读(历史版本);insert、update
和delete
会更新版本号,是当前读(当前版本)。
- 重新打开客户端
B
,插入一条新数据后提交
- 在客户端
A
查询表account的所有记录,没有查出新增数据,所以没有出现幻读
- 验证幻读,在客户端A执行
update account set balance=888 where id = 4;
能更新成功,再次查询能查到客户端B
新增的数据,可重复读隔离级别中出现了幻读
④:串行化
串行化 模式下,所有读写操作都会被加上行锁,这种隔离级别并发性极低,开发中很少会用到。
- 打开一个客户端
A
,并设置当前事务模式为serializable,set tx_isolation='serializable';
,查询表account的初始值,此时id=1
这一行数据已被加上行锁,别的事务无法操作!
- 打开一个客户端B,并设置当前事务模式为serializable,更新相同的
id为1
的记录会被阻塞等待,更新id为2
的记录可以成功。
4. mysql的锁机制
mysql
中的数据也是一种共享的资源,当并发访问时可能会出现数据一致性问题,所以mysql
使用一些锁机制去应对,但锁机制也是影响数据库并发访问性能的一个重要因素。
①:锁分类
- 悲观锁:悲观锁认为当前环境并发量非常大,为了在高并发情况下保证数据一致性,每次操作数据时需要进行加锁。保证安全的同时降低效率!mysql的
for update
就是一个悲观所- 应用:使用
synchronized
、Lock
,来处理高并发下产生线程不安全问题,这样会使其他线程进行挂起等待,从而影响系统吞吐量 - 悲观锁发生并发冲突,其他线程被挂起等待!
- 应用:使用
- 乐观锁:乐观锁i认为当前环境并发较少,或者很难出现并发,这时如果也使用
synchronized
、Lock
等悲观锁去处理,为了偶尔的并发降低每一次请求的效率,显然有些得不偿失。乐观锁采用版本机制对比, 如果有冲突,返回给用户错误的信息。仅返回错误信息相比于悲观锁的用户态和内核态的切换来讲是很快的!- 应用:无锁
CAS
,mybatis_plus
的乐观锁:@version
注解标记比较字段。mysql
更新时比对版版本号update ... where version = 1
,如果比对成功才能修改,否则提示错误 - 乐观锁发生并发冲突,返回错误信息或者自旋!与悲观锁的区别就是这点:宁愿返回错误也不要挂起其他线程!
- 应用:无锁
- 读锁:也叫共享锁,读锁会阻塞其他
session
的写,但是不会阻塞其他session
的读,属于悲观锁 - 写锁:也叫排它锁,写锁则会把其他
session
的读和写都阻塞。属于悲观锁MyISAM
在执行查询语句SELECT
前,会自动给涉及的所有表加读锁,在执行update、insert、delete
操作会自动给涉及的表加写锁。InnoDB
在执行查询语句SELECT
时(非串行隔离级别),不会加锁。但是update、insert、delete
操作会加行锁。
- 表锁:每次操作锁住整张表。开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低;一般用在整表数据迁移的场景。
- 行锁:行锁包括了共享锁、排他锁、间隙锁、记录锁、临键锁.,每次操作锁住一行数据。开销大,加锁慢;会出现死锁(事务修改完一行数据不提交,又去修改别的数据,两个事务相互持有锁不释放导致死锁);锁定粒度最小,发生锁冲突的概率最低,并发度最高。InnoDB支持行级锁,MYISAM不支持。InnoDB是针对索引加的锁,不是针对记录加的锁。
for update
就是mysql的行锁!表示锁住某一行,不允许其他事务读写数据。但for update
如果使用不当会升级成表锁- 使用
for update
查询非索引字段锁会升级为表锁。例如:wherer id = 1 for update
,id
为索引,此时为行锁;wherer name = aaa for update
,name
不是索引,此时会升级成表锁,锁住整张表,导致其他sql都操作不了数据库! - 因为
InnoDB
的更新会默认加行锁,所以如果对非索引字段更新,行锁也会变表锁。例如:session1
执行update account set balance = 800 where name = 'lilei';
,session2
对该表任一行操作都会阻塞住,并且该索引不能失效,否则都会从行锁升级为表锁 - 范围查询有时会升级为表锁。范围查询会锁上命中的所有间隙,
for update
也会升级为表锁 - 查全表也会导致
for update
升级为表锁,例如:select * from user for update
- 使用
- 间隙锁 (Gap Locks):锁的就是两个值之间的空隙,在可重复读隔离级别下才会生效。间隙锁在某些情况下可以解决幻读问题。
假设account
表里数据如下
- 那么间隙就有 id 为
(3,10)
,(10,20)
,(20,正无穷)
这三个区间 - 在事务A下面执行
update account set name = 'zhuge' where id > 8 and id <18;
,不提交事务 - 由于
id > 8 and id <18
处于(3,10)
,(10,20)
这两个区间内,那么由于事务A没有提交,mysql会使用间隙锁锁住(3,20]
这个区间内的所有数据。其他事务无法在(3,20]
这个区间内插入或修改任何数据。注意最后那个20
也是包含在内的,这就是间隙锁!
- 那么间隙就有 id 为
- 临键锁(Next-Key Locks):是行锁与间隙锁的组合。像上面那个例子里的这个
(3,20)
的这个区间是开区间,理论上其他事务操作id = 20
的数据是可以操作的,由于临键锁的存在,id = 20
的数据也变为不可操作。临键锁就是把(3,20)
的开区间变为闭区间(3,20]
;
InnoDB的加锁的方式:
InnoDB
行锁是通过给索引上的索引项加锁来实现的,如果不通过索引条件检索数据,那么InnoDB将对表中的所有记录加锁,实际效果跟表锁一样。那如何给索引项加锁:自动加锁。对于UPDATE、DELETE和INSERT语句,InnoDB会自动给涉及数据集加排他锁;对于普通SELECT语句,InnoDB不会加任何锁;当然我们也可以使用for update
显示的加锁
②:mysql不同操作的加锁规则
以下面这个表来进行实验说明,其中:
- id 是主键索引(唯一索引)
- b 是普通索引(非唯一索引)
- a 是普通的列。
CREATE TABLE `t_ab` (
`id` bigint NOT NULL AUTO_INCREMENT,
`a` int DEFAULT NULL COMMENT '列a',
`b` int DEFAULT NULL COMMENT '列b',
PRIMARY KEY (`id`) USING BTREE,
KEY `idx_a` (`a`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='ab';
唯一索引等值查询:
-
当查询的记录是存在的,临键锁
next-key lock
会退化成「记录锁」,只锁住当前记录id=16
,其他事务操作不受影响。如下所示:
-
当查询的记录是不存在的,临键锁
next-key lock
会退化成「间隙锁」,锁住当前id区域中,左开右开如:(8,16)
区间的数据,但操作id=16
不受影响!如下所示
非唯一索引等值查询:
-
当查询的记录存在时,除了会加 临键锁
next-key lock
外,还额外加间隙锁,也就是会加两把锁。如下会话1的普通索引 b 上共有两个锁,分别是next-key lock (4,8]
和间隙锁(8,16)
。- 先会对普通索引 b 加上 next-key lock,范围是
(4,8]
; - 然后因为是非唯一索引,且查询的记录是存在的,所以还会加上间隙锁,规则是向下遍历到第一个不符合条件的值才能停止,因此间隙锁的范围是
(8,16)
。
- 先会对普通索引 b 加上 next-key lock,范围是
-
当查询的记录不存在时,只会加 临键锁
next-key lock
,然后会退化为间隙锁,也就是只会加一把锁。- 由于
b = 5
查询记录是不存在的,所以不锁(4,8)
区间,但是要加临键锁next-key lock
,锁住下一个区间(8,16]
,然后退化成间隙锁(8,16)
!
- 由于
范围查询
非唯一索引和主键索引的范围查询的加锁规则不同之处在于:
-
唯一索引在满足一些条件的时候,临键锁
next-key lock
退化为间隙锁和记录锁。 -
会话 1 加锁变化过程如下:
- 最开始要找的第一行是
id = 8
,因此 next-key lock(4,8]
,但是由于 id 是唯一索引,且该记录是存在的,因此会退化成记录锁,也就是只会对id = 8
这一行加锁; - 由于是范围查找,就会继续往后找存在的记录,也就是会找到 id = 16 这一行停下来,然后加 next-key lock
(8, 16]
,但由于id = 16
不满足id < 9
,所以会退化成间隙锁,加锁范围变为(8, 16)
。 - 所以,会话 1 这时候主键索引的锁是
记录锁 id=8 和 间隙锁(8, 16)
,在这区间内部的所有事务都被阻塞!
- 最开始要找的第一行是
-
非唯一索引范围查询,临键锁
next-key lock
不会退化为间隙锁和记录锁。 -
会话 1 加锁变化过程如下:
- 最开始要找的第一行是 b = 8,因此 next-key lock
(4,8]
,但是由于 b 不是唯一索引,并不会退化成记录锁。 - 但是由于是范围查找,就会继续往后找存在的记录,也就是会找到 b = 16 这一行停下来,然后加 next-key lock
(8, 16]
,因为是普通索引查询,所以并不会退化成间隙锁。 - 所以,会话 1 的普通索引 b 有两个 next-key lock,分别是
(4,8]
和(8, 16]
。这样,你就明白为什么会话 2 、会话 3 、会话 4 的语句都会被锁住了。
- 最开始要找的第一行是 b = 8,因此 next-key lock
②:可重复读一定无法防止幻读吗?
不一定,间隙锁在某些情况下可以解决幻读问题。比如:在可重复读隔离级别下,事务A
如果对数据使用了范围操作,且未提交事务时,其他事务如果要操作事务A
的范围间隙中的数据,是会被阻塞的,由于其他事务被阻塞无法修改,就有了一点串行化隔离级别的意思,在这种情况下可重复读可以防止幻读!
③:行锁升级为表锁的原因
锁主要是加在索引上,如果对非索引字段更新,行锁可能会变表锁
假如有这张表:只有id
是主键索引,其他字段均无索引
现象:
- 事务
A
操作:update account set balance = 800 where name = 'lilei';
不提交事务 - 事务
B
操作时,对该表任一行操作都会阻塞住
原因:
事务A
在更新数据时,为该行数据加了行锁,但是sql执行计划没用到id
这个索引列,那么此时的行锁已经进化为表锁,在事务A
提交事务之前,针对这张表的操作都会被阻塞住!
结论:
InnoDB
的行锁是针对索引加的锁,不是针对记录加的锁。并且该索引不能失效,否则都会从行锁升级为表锁。
④:锁优化建议
- 尽可能让所有数据操作都通过索引来完成,避免无索引行锁升级为表锁
- 尽可能减少检索条件范围,避免间隙锁
- 涉及事务加行锁的sql尽量放在事务最后执行
- 尽可能使用低级别事务隔离级别