mysql的事务与锁机制

文章目录

1. 事务及其ACID属性
2. 事务并发带来的问题
3. 事务隔离级别
- ①：读未提交
- ②：读已提交
- ③：可重复读
- ④：串行化
4. mysql的锁机制
- ①：锁分类
- ②：mysql不同操作的加锁规则
- ②：可重复读一定无法防止幻读吗？
- ③：行锁升级为表锁的原因
- ④：锁优化建议

我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。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也是包含在内的，这就是间隙锁！
临键锁（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 是普通的列。

唯一索引等值查询：

当查询的记录是存在的，临键锁 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)。
当查询的记录不存在时，只会加临键锁 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 的语句都会被锁住了。

②：可重复读一定无法防止幻读吗？

不一定，间隙锁在某些情况下可以解决幻读问题。比如：在可重复读隔离级别下，事务A如果对数据使用了范围操作，且未提交事务时，其他事务如果要操作事务A的范围间隙中的数据，是会被阻塞的，由于其他事务被阻塞无法修改，就有了一点串行化隔离级别的意思，在这种情况下可重复读可以防止幻读！

③：行锁升级为表锁的原因

锁主要是加在索引上，如果对非索引字段更新，行锁可能会变表锁

假如有这张表：只有id是主键索引，其他字段均无索引

现象：

事务A操作：update account set balance = 800 where name = 'lilei';不提交事务
事务B操作时，对该表任一行操作都会阻塞住

原因：

事务A在更新数据时，为该行数据加了行锁，但是sql执行计划没用到id这个索引列，那么此时的行锁已经进化为表锁，在事务A提交事务之前，针对这张表的操作都会被阻塞住！

结论：

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。

④：锁优化建议

尽可能让所有数据操作都通过索引来完成，避免无索引行锁升级为表锁
尽可能减少检索条件范围，避免间隙锁
涉及事务加行锁的sql尽量放在事务最后执行
尽可能使用低级别事务隔离级别