mysql事务和锁

什么是数据库的事务？

事务的典型场景

在项目里面，什么地方会开启事务，或者配置了事务？无论是在方法上加注解，还 是配置切面

<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>

比如下单，会操作订单表，资金表，物流表等等，这个时候我们需要让这些操作都 在一个事务里面完成。当一个业务流程涉及多个表的操作的时候，我们希望它们要么是 全部成功的，要么都不成功，这个时候我们会启用事务。 在金融的系统里面事务配置是很常见的，比如行内转账的这种操作，如果我们把它简单地理解为一个账户的余额增加，另一个账户的余额减少的情况（当然实际上要比这 复杂），那么这两个动作一定是同时成功或者同时失败的，否则就会造成银行的会计科 目不平衡。

事务的定义

什么是事务？ 维基百科的定义：事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由 一个有限的数据库操作序列构成。 这里面有两个关键点，第一个，它是数据库最小的工作单元，是不可以再分的。第 二个，它可能包含了一个或者一系列的 DML 语句，包括 insert delete update。 （单条 DDL（create drop）和 DCL（grant revoke）也会有事务）

哪些存储引擎支持事务

InnoDB 支持事务，这个也是它成为默认的存储引擎 的一个重要原因：
https://dev.mysql.com/doc/refman/5.7/en/storage-engines.html
另一个是 NDB。

事务的四大特性

事务的四大特性：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 双写缓冲来实现的，我们操作数据的时候，5 会先写到内存的 buffer pool 里面，同时记录 redo log，如果在刷盘之前出现异常，在 重启后就可以读取 redo log 的内容，写入到磁盘，保证数据的持久性。 当然，恢复成功的前提是数据页本身没有被破坏，是完整的，这个通过双写缓冲 （double write）保证

原子性，隔离性，持久性，最后都是为了实现一致性。

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

无论是我们在 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，写入了。 这个就是我们开启和结束事务的两种方式。

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

当很多事务并发地去操作数据库的表或者行的时候，如果没有我们刚才讲的事务的 Isolation 隔离性的时候，会带来哪些问题呢？

脏读

我们有两个事务，一个是 Transaction A，一个是 Transaction B，在第一个事务里 面，它首先通过一个 where id=1 的条件查询一条数据，返回 name=Ada，age=16 的 这条数据。然后第二个事务，它同样地是去操作 id=1 的这行数据，它通过一个 update 的语句，把这行 id=1 的数据的 age 改成了 18，但是注意，它没有提交。 这个时候，在第一个事务里面，它再次去执行相同的查询操作，发现数据发生了变 化，获取到的数据 age 变成了 18。那么，这种在一个事务里面，由于其他的时候修改了 数据并且没有提交，而导致了前后两次读取数据不一致的情况，这种事务并发的问题， 我们把它定义成什么？
这个叫做脏读。 如果在转账的案例里面，我们第一个事务基于读取到的第二个事务未提交的余额进 行了操作，但是第二个事务进行了回滚，这个时候就会导致数据不一致。 这种读取到其他事务未提交的数据的情况，我们把它叫做脏读。

不可重复读

同样是两个事务，第一个事务通过 id=1 查询到了一条数据。然后在第二个事务里面 执行了一个 update 操作，这里大家注意一下，执行了 update 以后它通过一个 commit 提交了修改。然后第一个事务读取到了其他事务已提交的数据导致前后两次读取数据不 一致的情况，就像这里，age 到底是等于 16 还是 18，那么这种事务并发带来的问题， 我们把它叫做什么？ 这种一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情 况，我们把它叫做不可重复读。

幻读

在第一个事务里面我们执行了一个范围查询，这个时候满足条件的数据只有一条。 在第二个事务里面，它插入了一行数据，并且提交了。重点：插入了一行数据。在第一 个事务里面再去查询的时候，它发现多了一行数据。这种情况，我们把它叫做什么呢？== 一个事务前后两次读取数据数据不一致，是由于其他事务插入数据造成的，这种情 况我们把它叫做幻读。==

不可重复读和幻读，的区别在那里呢？ 不可重复读是修改或者删除，幻读是插入。

小结：我们刚才讲了事务并发带来的三大问题，现在来给大家总结一下。无论是脏 读，还是不可重复读，还是幻读，它们都是数据库的读一致性的问题，都是在一个事务 里面前后两次读取出现了不一致的情况。

SQL92 标准

所以，就有很多的数据库专家联合制定了一个标准，也就是说建议数据库厂商都按 照这个标准，提供一定的事务隔离级别，来解决事务并发的问题，这个就是 SQL92 标准。 我们来看一下 SQL92 标准的官网。
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

这里面有一张表格（搜索_iso），里面定义了四个隔离级别，右边的 P1 P2 P3 就是 代表事务并发的 3 个问题，脏读，不可重复读，幻读。Possible 代表在这个隔离级别下， 这个问题有可能发生，换句话说，没有解决这个问题。Not Possible 就是解决了这个问
题。我们详细地分析一下这 4 个隔离级别是怎么定义的。

• 第一个隔离级别叫做：Read Uncommitted（未提交读），一个事务可以读取到其 他事务未提交的数据，会出现脏读，所以叫做 RU，它没有解决任何的问题。 第二个隔离级别叫做：
• Read Committed（已提交读），也就是一个事务只能读取 到其他事务已提交的数据，不能读取到其他事务未提交的数据，它解决了脏读的问题， 但是会出现不可重复读的问题。 第三个隔离级别叫做：
• Repeatable Read (可重复读)，它解决了不可重复读的问题，== 也就是在同一个事务里面多次读取同样的数据结果是一样的，但是在这个级别下，没有 定义解决幻读的问题。== 最后一个就是：
• Serializable（串行化），在这个隔离级别里面，所有的事务都是串 行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决 了所有的问题。 这个是 SQL92 的标准，但是不同的数据库厂商或者存储引擎的实现有一定的差异， 比如 Oracle 里面就只有两种 RC（已提交读）和 Serializable（串行化）。那么 InnoDB 的实现又是怎么样的呢？

MySQL InnoDB 对隔离级别的支持

在 MySQL InnoDB 里面，不需要使用串行化的隔离级别去解决所有问题。那我们来 看一下 MySQL InnoDB 里面对数据库事务隔离级别的支持程度是什么样的。

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

两大实现方案

LBCC
第一种，我既然要保证前后两次读取数据一致，那么我读取数据的时候，锁定我要 操作的数据，不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制 Lock Based Concurrency Control（LBCC）。 如果仅仅是基于锁来实现事务隔离，一个事务读取的时候不允许其他时候修改，那 就意味着不支持并发的读写操作，而我们的大多数应用都是读多写少的，这样会极大地 影响操作数据的效率
MVCC
所以我们还有另一种解决方案，如果要让一个事务前后两次读取的数据保持一致，== 那么我们可以在修改数据的时候给它建立一个备份或者叫快照，后面再来读取这个快照 就行了==。这种方案我们叫做多版本的并发控制 Multi Version Concurrency Control （MVCC）。 MVCC 的核心思想是： 我可以查到在我这个事务开始之前已经存在的数据，即使它 在后面被修改或者删除了。在我这个事务之后新增的数据，我是查不到的。 问题：这个快照什么时候创建？读取数据的时候，怎么保证能读取到这个快照而不 是最新的数据？这个怎么实现呢？ InnoDB 为每行记录都实现了两个隐藏字段： DB_TRX_ID，6 字节：插入或更新行的最后一个事务的事务 ID，事务编号是自动递 增的（我们把它理解为创建版本号，在数据新增或者修改为新数据的时候，记录当前事 务 ID）。 DB_ROLL_PTR，7 字节：回滚指针（我们把它理解为删除版本号，数据被删除或记 录为旧数据的时候，记录当前事务 ID）。 我们把这两个事务 ID 理解为版本号。

MySQL InnoDB 锁的基本类型

https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html
官网把锁分成了 8 类。
所以我们把前面的两个行级别的锁（Shared and Exclusive Locks），
和两个表级别的锁（Intention Locks）称为锁的基本模式。
后面三个 Record Locks、Gap Locks、Next-Key Locks，我们把它们叫做锁的算法， 也就是分别在什么情况下锁定什么范围

锁的粒度

我们讲到 InnoDB 里面既有行级别的锁，又有表级别的锁，我们先来分析一下这两 种锁定粒度的一些差异。 表锁，顾名思义，是锁住一张表；行锁就是锁住表里面的一行数据。锁定粒度，表 锁肯定是大于行锁的。 那么加锁效率，表锁应该是大于行锁还是小于行锁呢？大于。为什么？表锁只需要 直接锁住这张表就行了，而行锁，还需要在表里面去检索这一行数据，所以表锁的加锁 效率更高。 第二个冲突的概率？表锁的冲突概率比行锁大，还是小？ 大于，因为当我们锁住一张表的时候，其他任何一个事务都不能操作这张表。但是 我们锁住了表里面的一行数据的时候，其他的事务还可以来操作表里面的其他没有被锁 定的行，所以表锁的冲突概率更大。 表锁的冲突概率更大，所以并发性能更低，这里并发性能就是小于。 innoDB 里面我们知道它既支持表锁又支持行锁，另一个常用的存储引擎 MyISAM 支 持什么粒度的锁？这是第一个问题。第二个就是 InnoDB 已经支持行锁了，那么它也可 以通过把表里面的每一行都锁住来实现表锁，为什么还要提供表锁呢？ 要搞清楚这个问题，我们就要来了解一下 InnoDB 里面的基本的锁的模式（lock mode），这里面有两个行锁和两个表锁。

共享锁

第一个行级别的锁就是我们在官网看到的 Shared Locks （共享锁），我们获取了 一行数据的读锁以后，可以用来读取数据，所以它也叫做读锁，注意不要在加上了读锁 以后去写数据，不然的话可能会出现死锁的情况。而且多个事务可以共享一把读锁。那怎么给一行数据加上读锁呢？ 我们可以用 select …… lock in share mode; 的方式手工加上一把读锁。 释放锁有两种方式，只要事务结束，锁就会自动事务，包括提交事务和结束事务。 我们也来验证一下，看看共享锁是不是可以重复获取。

排它锁

第二个行级别的锁叫做 Exclusive Locks（排它锁），它是用来操作数据的，所以又 叫做写锁。只要一个事务获取了一行数据的排它锁，其他的事务就不能再获取这一行数 据的共享锁和排它锁。 排它锁的加锁方式有两种，第一种是自动加排他锁。我们在操作数据的时候，包括 增删改，都会默认加上一个排它锁。 还有一种是手工加锁，我们用一个 ==FOR UPDATE 给一行数据加上一个排它锁，==这个 无论是在我们的代码里面还是操作数据的工具里面，都比较常用。 释放锁的方式跟前面是一样的

意向锁

意向锁是什么呢？我们好像从来没有听过，也从来没有使用过，其实他们是由数据 库自己维护的。 也就是说，当我们给一行数据加上共享锁之前，数据库会自动在这张表上面加一个 意向共享锁。 当我们给一行数据加上排他锁之前，数据库会自动在这张表上面加一个意向排他锁。 反过来说： 如果一张表上面至少有一个意向共享锁，说明有其他的事务给其中的某些数据行加 上了共享锁。 如果一张表上面至少有一个意向排他锁，说明有其他的事务给其中的某些数据行加 上了排他锁
那么这两个表级别的锁存在的意义是什么呢？第一个，我们有了表级别的锁，在 InnoDB 里面就可以支持更多粒度的锁。它的第二个作用，我们想一下，如果说没有意向 锁的话，当我们准备给一张表加上表锁的时候，我们首先要做什么？是不是必须先要去 判断有没其他的事务锁定了其中了某些行？如果有的话，肯定不能加上表锁。那么这个 时候我们就要去扫描整张表才能确定能不能成功加上一个表锁，如果数据量特别大，比 如有上千万的数据的时候，加表锁的效率是不是很低？ ==但是我们引入了意向锁之后就不一样了。我只要判断这张表上面有没有意向锁，如 果有，就直接返回失败。如果没有，就可以加锁成功。所以 InnoDB 里面的表锁，我们 可以把它理解成一个标志。==就像火车上厕所有没有人使用的灯，是用来提高加锁的效率 的

行锁的原理

1、锁住索引
(1)如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。
( 2）如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索 引作为主键索引。
(3）如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的== ROWID 作 为隐藏的聚集索引==，它会随着行记录的写入而主键递增。 所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐 藏的聚集索引都锁住了。

2、为什么==通过唯一索引给数据行加锁，主键索引也会被锁住，索引存储的是二级索引和主键的值。比如name=4，存储的是name 的索引和主键 id 的值 4。 而主键索引里面除了索引之外，还存储了完整的数据。==所以我们通过辅助索引锁定 一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引

锁的算法

记录锁

第一种情况，当我们对于唯一性的索引（包括唯一索引和主键索引）使用等值查询， 精准匹配到一条记录的时候，这个时候使用的就是记录锁。 比如 where id = 1 4 7 10 。 我们使用不同的 key 去加锁，不会冲突，它只锁 住这个 record。

间隙锁

当我们查询的记录不存在，没有命中任何一个 record，无论是用等值 查询还是范围查询的时候，它使用的都是间隙锁。 举个例子，where id >4 and id <7，where id = 6。
重复一遍，当查询的记录不存在的时候，使用间隙锁。 注意，间隙锁主要是阻塞插入 insert。相同的间隙锁之间不冲突。 Gap Lock 只在 RR 中存在。如果要关闭间隙锁，就是把事务隔离级别设置成 RC， 并且把 innodb_locks_unsafe_for_binlog 设置为 ON。 这种情况下除了外键约束和唯一性检查会加间隙锁，其他情况都不会用间隙锁。
线程1
begin;
INSERT INTO t2 (id, name) VALUES (5, ‘5’);
// BLOCKED INSERT INTO t2 (id, name) VALUES (6, ‘6’); // BLOCKED
select * from t2 where id =6 for update; // OK
线程2
select * from t2 where id >20 for update; INSERT INTO t2 (id, name) VALUES (11, ‘11’); // BLOCKED

临键锁

==第三种情况，当我们使用了范围查询，不仅仅命中了 Record 记录，还包含了 Gap 间隙，在这种情况下我们使用的就是临键锁，==它是 MySQL 里面默认的行锁算法，相当于 记录锁加上间隙锁。第三种情况，当我们使用了范围查询，不仅仅命中了 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,+∞)

查看锁信息（日志）

show status like 'innodb_row_lock_%';

Innodb_row_lock_current_waits：当前正在等待锁定的数量； Innodb_row_lock_time ：从系统启动到现在锁定的总时间长度，单位 ms； Innodb_row_lock_time_avg ：每次等待所花平均时间； Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间； Innodb_row_lock_waits ：从系统启动到现在总共等待的次数。

SHOW 命令是一个概要信息。InnoDB 还提供了三张表来分析事务与锁的情况

select * from information_schema.INNODB_TRX; -- 当前运行的所有事务 ，还有具体的语句

select * from information_schema.INNODB_LOCKS; -- 当前出现的锁

select * from information_schema.INNODB_LOCK_WAITS; -- 锁等待的对应关系

如果一个事务长时间持有锁不释放，可以 kill 事务对应的线程 ID，也就是 INNODB_TRX 表中的 trx_mysql_thread_id，例如执行 kill 4，kill 7，kill 8。 当然，死锁的问题不能每次都靠 kill 线程来解决，这是治标不治本的行为。

死锁的避免

1、 在程序中，操作多张表时，尽量以相同的顺序来访问（避免形成等待环路）；
2、 批量操作单张表数据的时候，先对数据进行排序（避免形成等待环路）；
3、 申请足够级别的锁，如果要操作数据，就申请排它锁；
4、 尽量使用索引访问数据，避免没有 where 条件的操作，避免锁表；
5、 如果可以，大事务化成小事务；
6、 使用等值查询而不是范围查询查询数据，命中记录，避免间隙锁对并发的影响