Mysql学习宝典（四） -- Mysql的事务与锁深入剖析

MySQL 事务与锁详解

什么是数据库的事务？

什么是事务？

​ 事务是数据库最小的工作单元，也就是说我们刚才提到的这些场景，它们是作为一个逻辑单元执行 的，既然是最小的工作单元，意味着它是不可再分的。这里面可能包含了一个或者一系列的 DML 语句。 单条 DDL（create drop）和 DCL（grant revoke）也会有事务。

哪些存储引擎支持事务？

​ InnoDB，NDB

事务的四大特性？

​ 原子性，Atomicity，意味着我们对数据库的一系列的操作，要么都是成功，要么都是失败，不可能出现部分成功或者部分失败的情况。

​ **思考：**都成功很容易保证。在前面的操作已经成功了的情况下，后面的操作失败了，怎么保证全部

​ 原子性，在 InnoDB 里面是通过 undo log 来实现的。

​ https://dev.mysql.com/doc/refman/5.7/en/innodb-undo-tablespaces.html

​ https://dev.mysql.com/doc/refman/5.7/en/innodb-undo-logs.html

​ undo log（撤销日志或回滚日志）记录了事务发生之前的数据状态（不包括 select），在发生异常执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态（回滚），而不是从物理页面上操作实现的，属于逻辑格式的日志。

​ 一致性，Consistent，指的是数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。比如主键必须是唯一的，字段长度符合要求。

​ 另一方面是用户自定义的完整性。

​ 比如转账，A 账户余额减少 1000，B 账户余额只增加了 500，这个时候因为两个操作都成功了，按照我们对原子性的定义，它是满足原子性的， 但是它没有满足一致性，因为它导致了会计科目的不平衡。

​ 还有一种情况，A 账户余额为 0，如果这个时候转账成功了，A 账户的余额会变成-1000，虽然它满足了原子性的，但是我们知道，借记卡的余额是不能够小于 0 的，所以也违反了一致性。

​ 隔离性，isolation，有了事务的定义以后，在数据库里面会有很多的事务同时去操作我们的同一张表或者同一行数据，必然会产生一些并发或者干扰的操作，对隔离性就是这些很多个的事务，对表或者 行的并发操作，应该是透明的，互相不干扰的。通过这种方式，我们最终也是保证业务数据的一致性。

​ 持久性，Durable，我们对数据库的任意的操作，增删改，只要事务提交成功，那么结果就是永久性的，不可能因为我们重启了数据库的服务器，它又恢复到原来的状态了。

​ **思考：**如果中途数据库崩溃，也要把 buffer pool 中的内容写入磁盘，我们是怎么实现的？

​ 持久性是通过 redo log 来实现的，我们操作数据的时候，会先写到内存的 buffer pool 里面，同事记录 redo log，如果这个时候发生了异常，就可以读取 redo log 的内容，写入到磁盘，保证数据的持久性。

数据库什么时候会出现事务？

​ 在 MySQL InnoDB 里面，我们去开启事务有两种方式，一种是自动的。InnoDB 里面有一个 autocommit的参数，autocommit 又分成两个级别，一个是 session 级别，一个是 global 级别。autocommit 代表是否自动提交。如果它的值是 true/on 的话，我们在操作数据的时候，会自动开启一个事务，和自动提交事务。否则的话，如果我们把 autocommit 设置成 false/off，那么数据库的事务就需要我们手动地去开启和手动地去结束。

​ 改成 false 以后就要手工开启和结束事务。手工开启也有几种方式，一种是用 begin；一种是用 starttransaction。

​ 结束也有两种方式，第一种就是提交一个事务，commit；还有一种就是 rollback，回滚的时候，事务也会结束。

事务并发会带来什么问题？

​ 在一个事务里面，由于其他的时候修改了数据并且没有提交，而导致了前后两次读取数据不一致的情况，这种事务并发的问题，我们把叫做脏读。

​ 如果在转账的案例里面，我们第一个事务基于读取到的第二个事务未提交的余额进行了操作，但是第二个事务进行了回滚，这个时候就会导致数据库不一致。

​ 一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，叫做不可重复读。

​ 一个事务前后两次读取数据数据不一致，是由于其他事务插入数据造成的，这种情况我们把它叫做幻读。

SQL92 标准

​ 数据库专家联合制定了一个标准，也就是说建议数据库厂商都按照这个标准，提供一定的事务隔离级别，来解决事务并发的问题，这个就是 SQL92 标准。

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

​ 这里面有一张表格**（搜索_iso）**，里面定义了四个隔离级别，右边的 P1 P2 P3 就是代表事务并发的 3个问题，脏读，不可重复读，幻读。

​ 第一个隔离级别叫做：Read Uncommitted（未提交读），它不需要解决任何的问题，也就是一个事务可以读取到其他事务未提交的数据，会出现脏读，所以叫做 RU。

​ 第二个隔离级别叫做：Read Committed（已提交读），它需要解决脏读的问题，也就是一个事务只能读取到其他事务已提交的数据，不能读取到其他事务未提交的数据，但是会出现不可重复读的问题。

​ 第三个隔离级别叫做：Repeatable Read (可重复读)，它解决了不可重复读的问题，也就是在同一个事务里面多次读取同样的数据结果是一样的，但是它没有定义解决幻读的问题。

​ 最后一个就是：Serializable（串行化），在这个隔离级别里面，所有的事务都是串行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决了所有的问题。

MySQL InnoDB 对隔离级别的支持

​ 在 MySQL InnoDB 里面，不需要使用串行化的隔离级别去解决所有问题。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J4Hx6Uz9-1629365841731)(
\image-20210819171421003.png)]

​ InnoDB 支持的四个隔离级别和 SQL92 定义的基本一致，隔离级别越高，事务的并发度就越低。唯一的区别就在于，InnoDB 在 RR 的级别就解决了幻读的问题，这个也是 InnoDB 默认使用 RR 作为事务隔离级别的原因，既保证了数据的一致性，又支持较高的并发度。

两大实现方案

​ 如果要解决读一致性的问题，保证一个事务中前后两次读取数据结果一致，实现事务隔离，应该怎么做？我们有哪一些方法呢？

​ 总体上来说，我们有两大类的方案。第一种，既然要保证前后两次读取数据一致，那么我读取数据的时候，锁定我要操作的数据，不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制 Lock Based Concurrency Control（LBCC）。

​ 如果仅仅是基于锁来实现事务隔离，一个事务读取的时候不允许其他时候修改，那就意味着不支持并发的读写操作，会极大地影响操作数据的效率。

​ 所以我们还有另一种解决方案，如果要让一个事务前后两次读取的数据保持一致，那么我们可以在更新数据的时候建立一个备份或者叫快照，后面再来读取这个快照就行了。这种方案我们叫做多版本的

​ 并发控制 Multi Version Concurrency Control（MVCC）。

​ https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html

​ MVCC 也是通过 Undo log 实现的。

​ 实际上这两种方案并不排斥，在 InnoDB 里面，这两种方案协同使用才能实现事务隔离级别。

MySQL InnoDB 锁的基本类型

官网：https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html

锁的基本模式——共享锁

​ 第一个行级别的锁就是我们在官网看到的 Shared Locks （共享锁），我们获取了一行数据的读锁以后，可以用来读取数据，所以它也叫做读锁。而且多个事务可以共享一把读锁。那怎么给一行数据加上读锁呢？

​ 我们可以用 select lock in share mode;的方式手工加上一把读锁。

​ 释放锁有两种方式，只要事务结束，锁就会自动事务，包括提交事务和结束事务。

锁的基本模式——排它锁

​ 第二个行级别的锁叫做 Exclusive Locks（排它锁），它是用来操作数据的，所以又叫做写锁。只要一个事务获取了一行数据的排它锁，其他的事务就不能再获取这一行数据的共享锁和排它锁。

​ 排它锁的加锁方式有两种，第一种是自动加排他锁，可能是同学们没有注意到的：

​ 我们在操作数据的时候，包括增删改，都会默认加上一个排它锁。

​ 还有一种是手工加锁，我们用一个 FOR UPDATE 给一行数据加上一个排它锁，这个无论是在我们的代码里面还是操作数据的工具里面，都比较常用。

​ 释放锁的方式跟前面是一样的。

锁的基本模式——意向锁

​ 意向锁是由数据库自己维护的。

​ 也就是说，当我们给一行数据加上共享锁之前，会自动在这张表上面加一个意向共享锁。

​ 当我们给一行数据加上排他锁之前，会自动在这张表上面加一个意向排他锁。

​ 反过来说：

​ 如果一张表上面至少有一个意向共享锁，说明有其他的事务给其中的某些数据行加上了共享锁。

​ 如果一张表上面至少有一个意向排他锁，说明有其他的事务给其中的某些数据行加上了排他锁。

​ 那么这两个表级别的锁存在的意义是什么呢？第一个，我们有了表级别的锁，在 InnoDB 里面就可以支持更多粒度的锁。它的第二个作用，我们想一下，如果说没有意向锁的话，当我们准备给一张表加上表锁的时候，我们首先要做什么？是不是必须先要去判断有没其他的事务锁定了其中了某些行？如果有的话，肯定不能加上表锁。那么这个时候我们就要去扫描整张表才能确定能不能成功加上一个表锁，如果数据量特别大，比如有上千万的数据的时候，加表锁的效率是不是很低？

​ 但是我们引入了意向锁之后就不一样了。我只要判断这张表上面有没有意向锁，如果有，就直接返回失败。如果没有，就可以加锁成功。所以 InnoDB 里面的表锁，我们可以把它理解成一个标志。就像火车上厕所有没有人使用的灯，是用来提高加锁的效率的。

锁的原理

没有索引的表（假设锁住记录）

​ 首先我们有三张表，一张没有索引的 t1，一张有主键索引的 t2，一张有唯一索引的 t3。

​ 我们先假设 InnoDB 的锁锁住了是一行数据或者一条记录。

​ 我们先来看一下 t1 的表结构，它有两个字段，int 类型的 id 和 varchar 类型的 name。里面有 4 条数据，1、2、3、4。

Transaction 1	Transaction 2
begin;
SELECT * FROM t1 WHERE id =1 FOR UPDATE;
	select * from t1 where id=3 for update; //blocked
	INSERT INTO t1 (id, name) VALUES (5, ‘5’); //blocked

​ 现在我们在两个会话里面手工开启两个事务。

​ 在第一个事务里面，我们通过 where id =1 锁住第一行数据。

​ 在第二个事务里面，我们尝试给 id=3 的这一行数据加锁——这个加锁的操作被阻塞了。

​ 我们再来操作一条不存在的数据，插入 id=5。它也被阻塞了。

​ 实际上这里整张表都被锁住了。所以，我们的第一个猜想被推翻了，InnoDB 的锁锁住的应该不是Record。

​ 那为什么在没有索引或者没有用到索引的情况下，会锁住整张表？

有主键索引的表（假设锁住字段）

​ 我们看一下 t2 的表结构。字段是一样的，不同的地方是 id 上创建了一个主键索引。里面的数据是 1、4、7、10。

Transaction 1	Transaction 2
begin;
SELECT * FROM t2 WHERE id =1 FOR UPDATE;
	select * from t2 where id=1 for update; //blocked
	select * from t2 where id=4 for update; // OK

​ 第一种情况，使用相同的 id 值去加锁，冲突；使用不同的 id 加锁，可以加锁成功。那么，既然不是锁定一行数据，有没有可能是锁住了 id 的这个字段呢？

唯一索引

​ t3 的表结构。字段还是一样的，id 上创建了一个主键索引，name 上创建了一个唯一索引。里面的数据是 1、4、7、10。

Transaction 1	Transaction 2
begin;
select * from t3 where name= ‘4’ for update;
	select * from t3 where name = ‘4’ for update; //blocked
	select * from t3 where id = 4 for update; // OK

​ 在第一个事务里面，我们通过 name 字段去锁定值是 4 的这行数据。

​ 在第二个事务里面，尝试获取一样的排它锁，肯定是失败的。

​ 在这里我们怀疑 innoDB 锁住的是字段，所以这次我换一个字段，用 id=4 去给这行数据加锁也被阻塞了，说明锁住的是字段的这个推测也是错的，否则就不会出现第一个事务锁住了 name,第二个字段锁住 id 失败的情况。

​ 既然锁住的不是 record，也不是 column，InnoDB 里面锁住的到底是什么呢？

​ 在这三个案例里面，我们要去分析一下他们的差异在哪里，也就是这三张表的结构，是什么区别导致了加锁的行为的差异？其实答案就是索引。InnoDB 的行锁，就是通过锁住索引来实现的。

​ 还有两个问题没有解决，一、为什么表里面没有索引的时候，加锁会导致锁表？

​ 这个问题其实要通过另一个问题来解决，也就是说，一张表有没有可能没有索引？不可能的。如果

一张表没有聚集索引，数据库就会自动创建一个默认的聚集索引，那么我们加锁的时候，由于是全表扫描，那么就会把每一行的隐藏的索引锁住，才会造成一个锁表的现象。

​ 第二个问题，为什么通过唯一索引给数据行加锁，主键索引也会被锁住？

​ 在辅助索引里面，索引存储的是二级索引和主键索引的键值。比如 name=4，存储的是 name 的索引和 id=4。

​ 而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键键值找到主键索引，然后也锁定。

​

锁的算法

​ t2 这张表 id 有一个主键索引。我们插入了 4 行数据，主键 id 分别是 1、4、7、10。

​ 我们这里的划分标准是主键 id。

​ 这些数据库里面存在的主键值，我们把它叫做 Record，记录，那么这里我们就有 4 个 Record。

​ 根据主键，这些存在的 Record 隔开的数据不存在的区间，我们把它叫做 Gap，间隙，它是一个左开右开的区间。

​ 假设我们有 N 个 Record，那么所有的数据会被划分成多少个 Gap 区间？答案是 N+1，就像我们把一条绳子砍 N 刀，它最后肯定是变成 N+1 段。

​ 最后一个，间隙（Gap）连同它左边的记录（Record），我们把它叫做临键的区间，它是一个左开右闭的区间。

​ 如果主键索引不是整型，是字符怎么办呢？字符可以排序吗？ 基于 ASCII 码。

记录锁

​ 第一种情况，当我们对于唯一性的索引（包括唯一索引和主键索引）使用等值查询，精准匹配到一条记录的时候，这个时候使用的就是记录锁。

​ 比如 where id = 1 4 7 10 。

间隙锁

​ 第二种情况，当我们查询的记录不存在，无论是用等值查询还是范围查询的时候，它使用的都是间隙锁。

​ 举个例子，where id >4 and id <7，where id = 6。Gap 锁只在 RR 事务隔离级别里面存在。

临键锁

​ 第三种情况，当我们使用了范围查询，不仅仅命中了 Record 记录，还包含了 Gap 间隙，在这种情况下我们使用的就是临键锁，它是 MySQL 里面默认的行锁算法，相当于记录锁加上间隙锁。

​ 比如我们使用>5 <9 ， 它包含了不存在的区间，也包含了一个 Record 7。

​ 锁住最后一个 key 的下一个左开右闭的区间。

select * from t2  where id >5 and id <=7 for update; 锁住(4,7]和(7,10] 

select * from t2 where id >8 and id <=10 for update; 锁住 (7,10]，(10,+∞)

Gap 间隙，在这种情况下我们使用的就是临键锁，它是 MySQL 里面默认的行锁算法，相当于记录锁加上间隙锁。

​ 比如我们使用>5 <9 ， 它包含了不存在的区间，也包含了一个 Record 7。

​ 锁住最后一个 key 的下一个左开右闭的区间。

select * from t2  where id >5 and id <=7 for update; 锁住(4,7]和(7,10] 

select * from t2 where id >8 and id <=10 for update; 锁住 (7,10]，(10,+∞)

​ 为什么要锁住下一个左开右闭的区间？——就是为了解决幻读的问题。