一，事务
1.1，事务的典型场景
在项目里面，什么地方会开启事务，或者配置了事务？无论是在方法上加注解，还是配置切面。
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="save*" rollback-for="Throwable" />
<tx:method name="add*" rollback-for="Throwable" />
<tx:method name="send*" rollback-for="Throwable" />
<tx:method name="insert*" rollback-for="Throwable" />
</tx:attributes>
</tx:advice>
比如下单，会操作订单表，资金表，物流表等等，这个时候我们需要让这些操作都 在一个事务里面完成。当一个业务流程涉及多个表的操作的时候，我们希望它们要么是全部成功的，要么都不成功，这个时候我们会启用事务。
在金融的系统里面事务配置是很常见的，比如行内转账的这种操作，如果我们把它简单地理解为一个账户的余额增加，另一个账户的余额减少的情况(当然实际上要比这复杂)，那么这两个动作一定是同时成功或者同时失败的，否则就会造成银行的会计科目不平衡。
1.2，事务的定义
什么是事务？
维基百科的定义：事务是数据库管理系统(DBMS)执行过程中的一个逻辑单位，由 一个有限的数据库操作序列构成。这里面有两个关键点，第一个，它是数据库最小的工作单元，是不可以再分的。第 二个，它可能包含了一个或者一系列的 DML 语句，包括 insert delete update。(单条 DDL(create drop)和 DCL(grant revoke)也会有事务)
1.3，哪些存储引擎支持事务
1.4，事务的四大特性
事务的四大特性：ACID。
Atomicity(原子性)
就意味着我们对数据库的一系列的操作，要么都是成功，要么都是失败，不可能出现部分成功或者部分失 败的情况。以转账的场景为例，一个账户的余额减少，对应一个账户的增加，这两个一定是同时成功或者同时失败的。全部成功比较简单，问题是如果前面一个操作已经成功了，后面的操作失败了，怎么让它全部失败呢？这个时候我们必须要回滚。原子性，在 InnoDB 里面是通过 undo log 来实现的，它记录了数据修改之前的值(逻辑日志)，一旦发生异常，就可以用 undo log 来实现回滚操作。
consistent(一致性)
指的是数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。比如主键必须是唯一的，字段长度符合要求。除了数据库自身的完整性约束，还有一个是用户自定义的完整性。比如说转账的这个场景，A 账户余额减少 1000，B 账户余额只增加了 500，这个时候因为两个操作都成功了，按照我们对原子性的定义，它是满足原子性的， 但是它没有满足一致性，因为它导致了会计科目的不平衡。还有一种情况，A 账户余额为 0，如果这个时候转账成功了，A 账户的余额会变成 -1000，虽然它满足了原子性的，但是我们知道，借记卡的余额是不能够小于 0 的，所以也违反了一致性。用户自定义的完整性通常要在代码中控制。
Isolation(隔离性)
在数据库里面会有很多的 事务同时去操作我们的同一张表或者同一行数据，必然会产生一些并发或者干扰的操作， 那么我们对隔离性的定义，就是这些很多个的事务，对表或者行的并发操作，应该是透明的，互相不干扰的。通过这种方式，我们最终也是保证业务数据的一致性。
Durable(持久性)
事务的持久性是什么意思呢？我们对数据库的任意的操作，增删改，只要事务提交成功，那么结果就是永久性的，不可能因为我们系统宕机或者重启了数据库的服务器，它又恢复到原来的状态了。这个就是事务的持久性。
持久性怎么实现呢？数据库崩溃恢复(crash-safe)是通过什么实现的？
持久性是通过 redo log 和 double write 双写缓冲来实现的，我们操作数据的时候， 会先写到内存的 buffer pool 里面，同时记录 redo log，如果在刷盘之前出现异常，在重启后就可以读取 redo log 的内容，写入到磁盘，保证数据的持久性。当然，恢复成功的前提是数据页本身没有被破坏，是完整的，这个通过双写缓冲 (double write)保证。
原子性，隔离性，持久性，最后都是为了实现一致性。
1.5，数据库什么时候会出现事务
无论是我们在 Navicat 的这种工具里面去操作，还是在我们的 Java 代码里面通过 API 去操作，还是加上@Transactional 的注解或者 AOP 配置，其实最终都是发送一个指令到数据库去执行，Java 的 JDBC 只不过是把这些命令封装起来了。我们先来看一下我们的操作环境。版本(5.7)，存储引擎(InnnoDB)，事务隔离级别(RR)
select version(); show variables like '%engine%'; show global variables like "tx_isolation";
执行这样一条更新语句的时候，它有事务吗？
update student set sname = '猫老公 111' where id=1;
实际上，它自动开启了一个事务，并且提交了，所以最终写入了磁盘。这个是开启事务的第一种方式，自动开启和自动提交。InnoDB 里面有一个 autocommit 的参数(分成两个级别， session 级别和 global 级别)。
show variables like 'autocommit';
它的默认值是 ON。autocommit 这个参数是什么意思呢？
是否自动提交。如果它的 值是 true/on 的话，我们在操作数据的时候，会自动开启一个事务，和自动提交事务。否则，如果我们把 autocommit 设置成 false/off，那么数据库的事务就需要我们手动地去开启和手动地去结束。
手动开启事务也有几种方式，一种是用 begin；一种是用 start transaction。
那么怎么结束一个事务呢？我们结束也有两种方式，第一种就是提交一个事务， commit；还有一种就是 rollback，回滚的时候，事务也会结束。还有一种情况，客户端的连接断开的时候，事务也会结束。
当我们结束一个事务的时候，事务持有的锁就会被释放，无论是 提交还是回滚。我们用 begin 手工开启一个事务，执行第二个 update，但是数据没有写入磁盘，因 为事务还没有提交，这个时候 commit 一下，再刷新一下，OK，写入了。这个就是我们开启和结束事务的两种方式。
1.6, 事务并发会带来什么问题？
1.6.1 脏读
我们有两个事务，一个是 Transaction A，一个是 Transaction B，在第一个事务里 面，它首先通过一个 where id=1 的条件查询一条数据，返回 name=Ada，age=16 的这条数据。然后第二个事务，它同样地是去操作 id=1 的这行数据，它通过一个 update的语句，把这行 id=1 的数据的 age 改成了 18，但是注意，它没有提交。这个时候，在第一个事务里面，它再次去执行相同的查询操作，发现数据发生了变 化，获取到的数据 age 变成了 18。那么，这种在一个事务里面，由于其他的时候修改了数据并且没有提交，而导致了前后两次读取数据不一致的情况，这种事务并发的问题，我们把它定义成什么？这个叫做脏读。如果在转账的案例里面，我们第一个事务基于读取到的第二个事务未提交的余额进行了操作，但是第二个事务进行了回滚，这个时候就会导致数据不一致。这种读取到其他事务未提交的数据的情况，我们把它叫做脏读。
1.6.2 不可重复读
同样是两个事务，第一个事务通过 id=1 查询到了一条数据。然后在第二个事务里面执行了一个 update 操作，这里大家注意一下，执行了 update 以后它通过一个 commit提交了修改。然后第一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，就像这里，age 到底是等于 16 还是 18，那么这种事务并发带来的问题，我们把它叫做什么？这种一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，我们把它叫做不可重复读。
1.6.3 幻读
在第一个事务里面我们执行了一个范围查询，这个时候满足条件的数据只有一条。在第二个事务里面，它插入了一行数据，并且提交了。重点：插入了一行数据。在第一 个事务里面再去查询的时候，它发现多了一行数据。这种情况，我们把它叫做什么呢？一个事务前后两次读取数据数据不一致，是由于其他事务插入数据造成的，这种情况我们把它叫做幻读。
不可重复读和幻读，的区别在那里呢？
不可重复读是修改或者删除，幻读是插入。
小结
我们刚才讲了事务并发带来的三大问题，现在来给大家总结一下。无论是脏读，还是不可重复读，还是幻读，它们都是数据库的读一致性的问题，都是在一个事务里面前后两次读取出现了不一致的情况。
读一致性的问题，必须要由数据库提供一定的事务隔离机制来解决。就像我们去饭店吃饭，基本的设施和卫生保证都是饭店提供的。那么我们使用数据库，隔离性的问题也必须由数据库帮助我们来解决。
1.7， SQL92标准
这里面有一张表格(搜索_iso)，里面定义了四个隔离级别，右边的 P1 P2 P3 就是 代表事务并发的 3 个问题，脏读，不可重复读，幻读。Possible 代表在这个隔离级别下，这个问题有可能发生，换句话说，没有解决这个问题。Not Possible 就是解决了这个问题。
我们详细地分析一下这 4 个隔离级别是怎么定义的。
Read Uncommitted(未提交读)
一个事务可以读取到其 他事务未提交的数据，会出现脏读，所以叫做 RU，它没有解决任何的问题。
Read Committed(已提交读)
一个事务只能读取 到其他事务已提交的数据，不能读取到其他事务未提交的数据，它解决了脏读的问题，但是会出现不可重复读的问题。
Repeatable Read (可重复读)
它解决了不可重复读的问题，也就是在同一个事务里面多次读取同样的数据结果是一样的，但是在这个级别下，没有定义解决幻读的问题。
Serializable(串行化)
在这个隔离级别里面，所有的事务都是串行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决了所有的问题。
这个是 SQL92 的标准，但是不同的数据库厂商或者存储引擎的实现有一定的差异， 比如 Oracle 里面就只有两种 RC(已提交读)和 Serializable(串行化)。那么 InnoDB的实现又是怎么样的呢？
1.8 ，MySQL InnoDB 对隔离级别的支持
在 MySQL InnoDB 里面，不需要使用串行化的隔离级别去解决所有问题。那我们来看一下 MySQL InnoDB 里面对数据库事务隔离级别的支持程度是什么样的。
InnoDB 支持的四个隔离级别和 SQL92 定义的基本一致，隔离级别越高，事务的并发度就越低。唯一的区别就在于，InnoDB 在 RR 的级别就解决了幻读的问题。这个也是InnoDB 默认使用 RR 作为事务隔离级别的原因，既保证了数据的一致性，又支持较高的并发度。
1.9，两大实现方案
那么大家想一下，如果要解决读一致性的问题，保证一个事务中前后两次读取数据 结果一致，实现事务隔离，应该怎么做？我们有哪一些方法呢？你的思路是什么样的呢？总体上来说，我们有两大类的方案。
1.9.1 LBCC
第一种，我既然要保证前后两次读取数据一致，那么我读取数据的时候，锁定我要操作的数据，不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制 Lock Based Concurrency Control(LBCC)。如果仅仅是基于锁来实现事务隔离，一个事务读取的时候不允许其他时候修改，那就意味着不支持并发的读写操作，而我们的大多数应用都是读多写少的，这样会极大地影响操作数据的效率。
1.9.2 MVCC
所以我们还有另一种解决方案，如果要让一个事务前后两次读取的数据保持一致，那么我们可以在修改数据的时候给它建立一个备份或者叫快照，后面再来读取这个快照就行了。这种方案我们叫做多版本的并发控制 Multi Version Concurrency Control(MVCC)。MVCC 的核心思想是：我可以查到在我这个事务开始之前已经存在的数据，即使它在后面被修改或者删除了。在我这个事务之后新增的数据，我是查不到的。
问题：这个快照什么时候创建？读取数据的时候，怎么保证能读取到这个快照而不 是最新的数据？这个怎么实现呢？
InnoDB 为每行记录都实现了两个隐藏字段：
DB_TRX_ID，6 字节：插入或更新行的最后一个事务的事务 ID，事务编号是自动递增的(我们把它理解为创建版本号，在数据新增或者修改为新数据的时候，记录当前事务 ID)。
DB_ROLL_PTR，7 字节：回滚指针(我们把它理解为删除版本号，数据被删除或记录为旧数据的时候，记录当前事务 ID)。
我们把这两个事务 ID 理解为版本号。
MVCC 演示图
在 InnoDB 中，MVCC 是通过 Undo log 实现的。Oracle、Postgres 等等其他数据库都有 MVCC 的实现。需要注意，在 InnoDB 中，MVCC 和锁是协同使用的，这两种方案并不是互斥的。
第一大类解决方案是锁，锁又是怎么实现读一致性的呢？
二，MySQL InnoDB 锁的基本类型
官网把锁分成了 8 类。所以我们把前面的两个行级别的锁(Shared and Exclusive Locks)，和两个表级别的锁(Intention Locks)称为锁的基本模式。后面三个 Record Locks、Gap Locks、Next-Key Locks，我们把它们叫做锁的算法，也就是分别在什么情况下锁定什么范围。
2.1，锁的粒度
我们讲到 InnoDB 里面既有行级别的锁，又有表级别的锁，我们先来分析一下这两种锁定粒度的一些差异。
表锁，顾名思义，是锁住一张表；
行锁就是锁住表里面的一行数据。
2.1.1 锁定粒度
表锁肯定是大于行锁的。
2.1.2 加锁效率
表锁应该是大于行锁还是小于行锁呢？
大于。为什么？表锁只需要直接锁住这张表就行了，而行锁，还需要在表里面去检索这一行数据，所以表锁的加锁效率更高。
2.1.3 冲突概率
表锁的冲突概率比行锁大，还是小？
大于，因为当我们锁住一张表的时候，其他任何一个事务都不能操作这张表。但是我们锁住了表里面的一行数据的时候，其他的事务还可以来操作表里面的其他没有被锁定的行，所以表锁的冲突概率更大。表锁的冲突概率更大，所以更低，这里并发性能就是。
2.1.4 并发性能
表锁的冲突概率比行锁大，还是小？
小于，表锁的冲突概率更大。表锁的冲突概率更大，所以小于
2.1.5 小结
表锁与行锁的区别：
锁定粒度：表锁>行锁
加锁效率：表锁>行锁
冲突概率：表锁>行锁
并发性能：表锁<行锁
InnoDB 里面我们知道它既支持表锁又支持行锁，另一个常用的存储引擎 MyISAM 支持什么粒度的锁？这是第一个问题。第二个就是 InnoDB 已经支持行锁了，那么它也可以通过把表里面的每一行都锁住来实现表锁，为什么还要提供表锁呢？要搞清楚这个问题，我们就要来了解一下 InnoDB 里面的基本的锁的模式(lock mode)，这里面有两个行锁和两个表锁。
2.2 ，共享锁
第一个行级别的锁就是我们在官网看到的 Shared Locks (共享锁)，我们获取了一行数据的读锁以后，可以用来读取数据，所以它也叫做读锁，注意不要在加上了读锁以后去写数据，不然的话可能会出现死锁的情况。而且多个事务可以共享一把读锁。那怎么给一行数据加上读锁呢？我们可以用 select …… lock in share mode; 的方式手工加上一把读锁。释放锁有两种方式，只要事务结束，锁就会自动事务，包括提交事务和结束事务。我们也来验证一下，看看共享锁是不是可以重复获取。
| Transaction 1 | Transaction 2 |
|---|---|
| begin; | |
| SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE; | |
| begin; | |
| SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE; //OK |
2.3， 排他锁
第二个行级别的锁叫做 Exclusive Locks(排它锁)，它是用来操作数据的，所以又叫做写锁。只要一个事务获取了一行数据的排它锁，其他的事务就不能再获取这一行数据的共享锁和排它锁。
排它锁的加锁方式有两种，第一种是自动加排他锁。我们在操作数据的时候，包括增删改，都会默认加上一个排它锁。
还有一种是手工加锁，我们用一个 FOR UPDATE 给一行数据加上一个排它锁，这个无论是在我们的代码里面还是操作数据的工具里面，都比较常用。释放锁的方式跟前面是一样的。
排他锁的验证：
| Transaction 1 | Transaction 2 |
|---|---|
| begin; | |
| UPDATE student SET sname = ‘猫老公 555’ WHERE id=1; | |
| begin; | |
| SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE;//blocked SELECT * FROM student where id=1 FOR UPDATE; //blocked DELETE FROM student where id=1 ; //blocked |
2.4， 意向锁
意向锁是什么呢？我们好像从来没有听过，也从来没有使用过，其实他们是由数据库自己维护的。也就是说，当我们给一行数据加上共享锁之前，数据库会自动在这张表上面加一个意向共享锁。当我们给一行数据加上排他锁之前，数据库会自动在这张表上面加一个意向排他锁。
反过来说：
如果一张表上面至少有一个意向共享锁，说明有其他的事务给其中的某些数据行加上了共享锁。如果一张表上面至少有一个意向排他锁，说明有其他的事务给其中的某些数据行加上了排他锁。
那么这两个表级别的锁存在的意义是什么呢？第一个，我们有了表级别的锁，在InnoDB 里面就可以支持更多粒度的锁。它的第二个作用，我们想一下，如果说没有意向锁的话，当我们准备给一张表加上表锁的时候，我们首先要做什么？是不是必须先要去判断有没其他的事务锁定了其中了某些行？如果有的话，肯定不能加上锁。那么这个 时候我们就要去扫描整张表才能确定能不能成功加上一个表锁，如果数据量特别大，比如有上千万的数据的时候，加表锁的效率是不是很低？但是我们引入了意向锁之后就不一样了。我只要判断这张表上面有没有意向锁，如果有，就直接返回失败。如果没有，就可以加锁成功。所以 InnoDB 里面的表锁，我们可以把它理解成一个标志。就像火车上厕所有没有人使用的灯，是用来提高加锁的效率的。
| Transaction 1 | Transaction 2 |
|---|---|
| begin; | |
| SELECT * FROM student where id=1 FOR UPDATE; | |
| BEGIN; | |
| LOCK TABLES student WRITE; //blocked UNLOCK TABLES; // 释放表锁的方式 |
三，行锁的原理
3.1，没有索引的表(假设锁住记录)
首先我们有三张表，一张没有索引的 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=1 的这行数据，为什么我不能操作 id=3 的数据呢？我们再来操作一条不存在的数据，插入 id=5。它也被阻塞了。实际上这里整张表都被锁住了。所以，我们的第一个猜想被推翻了，InnoDB 的锁锁住的应该不是 Record。那为什么在没有索引或者没有用到索引的情况下，会锁住整张表？这个问题我们先留在这里。我们继续看第二个演示。
3.2，有主键索引的表
我们看一下 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 的这个字段呢？
3.3，唯一索引(假设锁住字段)
我们看一下 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;//blocked |
在第一个事务里面，我们通过 name 字段去锁定值是 4 的这行数据。在第二个事务里面，尝试获取一样的排它锁，肯定是失败的，这个不用怀疑。在这里我们怀疑 InnoDB 锁住的是字段，所以这次我换一个字段，用 id=4 去给这行数据加锁，大家觉得能成功吗？很遗憾，又被阻塞了，说明锁住的是字段的这个推测也是错的，否则就不会出现第 一个事务锁住了 name，第二个字段锁住 id 失败的情况。既然锁住的不是 record，也不是 column，InnoDB 里面锁住的到底是什么呢？在这 三个案例里面，我们要去分析一下他们的差异在哪里，也就是这三张表的结构，是什么区别导致了加锁的行为的差异？其实答案就是索引。InnoDB 的行锁，就是通过锁住索引来实现的。
3.4 ，两个问题
3.4.1，为什么表里面没有索引的时候，锁住一行数据会导致锁表？或者说，如果锁住的是索引，一张表没有索引怎么办？所以，一张表有没有可能没有索引？
1)如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。
2)如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索 引作为主键索引。
3)如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作 为隐藏的聚集索引，它会随着行记录的写入而主键递增。所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。
3.4.2，为什么通过唯一索引给数据行加锁，主键索引也会被锁住？
大家还记得在 InnoDB 里面，当我们使用辅助索引的时候，它是怎么检索数据的吗？辅助索引的叶子节点存储的是什么内容？在辅助索引里面，索引存储的是二级索引和主键的值。比如name=4，存储的是name 的索引和主键 id 的值 4。而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然后也锁定。
现在我们已经搞清楚 4 个锁的基本类型和锁的原理了，在官网上，还有 3 种锁，我们把它理解为锁的算法。我们也来看下 InnoDB 在什么时候分别锁住什么范围。
来源：GPer-专业的IT技术问答社区
链接：https://gper.club/articles/7e7e7f7ff4g5egc6g68
扫一扫
978
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
