MySQL的事务与锁解析数据库qq42145271的博客-

一、什么是事务

1. 使用场景

项目里面，比如有涉及到转账、操作订单之类的，我们需要让这些操作在一个事务里面完成，这些操作要么全部成功，要么全部失败，不可能再一个事务里面出现A操作成功，B操作失败的情况。

2. 事务定义

百科显示：事务是数据库操作系统执行过程中的一个逻辑单位，由一系列的数据库操作序列组成。
有两个要点：
第一它是数据库最小的工作单元，是不可再分的
第二它包含了一系列的操作语句，比如insert，delete，update

3. 哪些存储引擎支持事务

MySQL的InnoDB，另外一个就是NDB。
下面是MySQL官网的存储引擎对比。

4.事务的四大特性

原子性（Atomicity），一致性（Consistency），隔离性（Isolation），永久性（Durability）

原子性：也就是我们所说的不可再分，我们对数据库的一系列操作要么全部成功，要么全部失败，比如转账，不可能出现A账户余额减少，B账户余额没变化，全部成功就万事大吉，如果其中某一步失败就必须要事务回滚。

原子性在InnoDB里面是通过undo log实现的，它记录了数据修改之前的值，是以逻辑日志的形式，如果发生回滚，就可以通过undo log来实现。

一致性：指的是数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。比如主键必须是唯一的，字段长度符合要求。
除了数据库自身的完整性约束，还有一个是用户自定义的完整性。比如转账前和转账后的金额总数应该是不变的，不可能出现A扣除了1000元，B只接收了500元。

隔离性：数据库里面会有很多的事务同时去操作我们的同一张表或者同一行数据，必然会产生一些并发或者干扰的操作，那么我们对隔离性的定义，就是这些很多个的事务，对表或者行的并发操作，应该是透明的，互相不干扰的。通过这种方式，我们最终也是保证业务数据的一致性，表明事务必须是相互独立的，不应该依赖或者影响其他事务。

持久性：我们对数据库的任意的操作，增删改，只要事务提交成功，那么结果就是永久性的，不可能因为我们系统宕机或者重启了数据库的服务器，它又恢复到原来的状态了。这个就是事务的持久性。事务完成后，对数据的修改永久保存到数据库和磁盘。

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

5.提交和回滚事务

不论我们是在数据库连接工具或者Java代码里面，最终都是发送一个指令到数据库执行，工具和代码不过是把命令给封装了。
InnoDB有一个参数就是autocommit，就是是否自动提交的意思。它有两个级别，session和global。
show variables like ‘autocommit’；默认值是ON，如果是OFF或者false就是关闭自动提交，需要我们手动提交事务。如果是ON或者true就是自动提交事务。
手动提交事务有两种，一种是begin，一种是start transaction
结束事务也有两种，一种是提交事务commit，一种是回滚rollback
还有一种情况，当客户端连接断开时，事务也会自动结束。

6. 事务并发带来了什么问题

如果没有事务，那么会有什么问题？
脏读：一个事务读取到了其他事务没有提交的数据，叫脏数据，就是脏读。
不可重复读：一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，就是不可重复读。
幻读：一个事务前后两次读取数据数据不一致，是由于其他事务插入数据造成的，这个就是幻读。
注意：不可重复读是指在一个事务中，两次查询的结果不一样，它针对的是更新（update）操作，幻读是在一个事务中，两次查询结果不一样，它针对的是添加（insert）操作。

7. 隔离级别

Read Uncommitted（未提交读）：一个事务可以读取到其他事务未提交的数据，会出现脏读，它没有解决任何的问题
Read Committed（已提交读）：也就是一个事务只能读取到其他事务已提交的数据，不能读取到其他事务未提交的数据，它解决了脏读的问题
Repeatable Read (可重复读)：它解决了不可重复读、脏读的问题，也就是在同一个事务里面多次读取同样的数据结果是一样的
Serializable（串行化）：在这个隔离级别里面，所有的事务都是串行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决了所有的问题。

8. MySQL对InnoDB的支持

MySQL InnoDB 里面，不需要使用串行化的隔离级别去解决所有问题，它的默认隔离级别是可重复读，就可以解决所有的并发问题。

9. 一致性两种实现方案

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）

在 InnoDB 中，MVCC 是通过 Undo log 实现的。Oracle、Postgres 等等其他数据库都有 MVCC 的实现。需要注意，在 InnoDB 中，MVCC 和锁是协同使用的，这两种方案并不是互斥的

二、InnoDB的锁

MySQL官网的锁有8种，Shared and Exclusive Locks是行级别的锁，Intention Locks是表级别的锁，统称为锁的基本模式。
后面Record Locks、Gap Locks、Next-Key Locks，我们把它们叫做锁的算法，也就是分别在什么情况下锁定什么范围

1. 锁的粒度

表锁：顾名思义，表锁就是把整张表给锁住
行锁：就是锁住表里面的一行数据
锁的粒度：表锁肯定是大于行锁的
加锁效率：表锁大于行锁，表锁直接锁表就好了，行锁还需要去查询这一行数据，然后加锁
冲突概率：表锁冲突大于行锁，因为表锁，其他任何事务都不能操作这张表，但是行锁只是锁定一行数据，其他事务还可以继续操作表里面其他的数据
并发性能：因为表锁冲突更大，所以并发性能更低，并发性能小于行锁的。

2. 共享锁

第一个行级别的锁就是Shared Locks（共享锁），我们获取了一行数据以后，可以读取数据，所以也叫读锁，注意不要在读锁之后再写数据，有可能造成死锁。多个事务可以共享一把读锁
我们可以在SQL语句的后面加上lock in share mode就可以加共享锁。
释放锁，只要事务结束，锁就会自自动释放，包括结束事务和提交事务。

3. 排它锁

第二个行级别的锁就是Exclusive Locks（排它锁），它是用来操作数据，所以也叫做写锁，只要一个事务获取了排它锁，其他的事务就不能获取这一行数据的共享锁和排它锁。
排它锁有两种加锁方式，一种是自动加锁，我们操作数据时候，增删改都会默认加上排它锁。还有一种是手动加锁，SQL后面加上for update就加了一个排它锁。

4. 意向锁

意向锁一般是数据库自己维护的，用户不能私自加意向锁。
我们给一行数据加上共享锁之前，数据库都会自动在这张表上面加一个意向共享锁，当我们给一行数据加上排它锁之前，数据库会自动在这张表上面加一个意向排它锁。
通俗点说：
如果一张表上面有意向共享锁，说明有其他的事务给其中的一些数据行加了共享锁。
如果一张表上面有意向排它锁，说明有其他的事务给其中的一些数据行加了排他锁。
意义是什么？？？
第一个：有了表级别的锁，在InnoDB里面可以支持更多粒度的锁，
第二个：提高加锁效率。
想一下，如果没有意向锁的话，我们准备给一张表加上表锁，我们首先要做什么？？？
是不是必须要去判断有没有其他的事务给表中的某些数据上锁，如果有上锁，那么我们肯定不能加表锁，那么我们就需要去扫描整个表才能知道能不能加表锁，如果表数据量特别大，加锁的效率不是很低？？？

但是如果加了意向锁，我们只需要判断这张表上面有没有意向锁就可以了，如果有，直接返回加锁失败，如果没有就加锁成功。

所以这个意向锁可以比喻成一个标志，比如火车上厕所的指示灯，意向锁它是用来提高我们加锁的效率。

共享锁，排它锁，意向共享锁，意向排它锁，这4种就是基本的锁的模式，或者叫锁的类型。

到这里思考两个问题：
锁的作用到底是什么？
它跟 Java 里面的锁是一样的，是为了解决资源竞争的问题，Java 里面的资源是对象，数据库的资源就是数据表或者数据行。
所以锁是用来解决事务对数据的并发访问的问题的
锁到底锁住了什么？
当一个事务锁住了一行数据的时候，其他的事务不能操作这一行数据，那它到底是锁住了这一行数据，还是锁住了这一个字段，还是锁住了别的什么东西呢？

三、锁的原理

1. 在没有索引或者没有使用索引的情况下，会锁住整张表。
2. 锁住的不是记录也不是字段，其实锁住的是索引。
   InnoDB的行锁，就是通过锁住索引来实现的。

那么又有两个问题？？？

1.为什么表里面没有索引，锁住一行数据会导致锁表？？？或者说如果锁住的是索引，一张表没有索引怎么办？？？

• 如果我们定义了主键（PRIMARY KEY），那么InnoDB会选择主键作为聚集索引，也叫聚簇索引。
• 如果没有定义主键，那么InnoDB会选择一个不包含null值的唯一索引作为主键索引。
• 如果也没有唯一索引，InnoDB会选择内置的6字节长度的rowId作为隐藏的聚集索引，这个ID会随着行记录的写入而递增。

所以为什么会锁表，是因为查询没有使用索引，会全表扫描，然后把每一个隐藏的聚集索引都给锁住了。

2. 为什么通过唯一索引给行加锁，主键索引也会被锁住？？？
   首先要知道辅助索引是怎么查询数据的，辅助索引的叶子节点存储了什么内容？
   辅助索引里面，索引存储的是二级索引和主键的值，而主键索引里面除了索引外还存储了完整的数据。
   所以我们通过辅助索引锁定一行数据的时候，会通过主键的值找到主键索引，然后也锁定。

四、锁的算法

比如我们有一张表，两个字段，id和name，id的值是1，4，7，10

依据第一个图，这种数据库里面存在的主键值，我们叫Record，也就是记录锁，那么我们有4个Record。
第二幅图根据主键，这些存在的Record隔开的数据不存在的区间，我们叫做Gap，间隙锁，它是一个左开右开的区间。
最后一个，间隙（Gap）和左边的记录（Record），叫做临键锁，它是左开右闭的区间。
主键是整形的可以排序，如果索引不是整形，是字符的话，用ASCII码来排序。
下面来看锁是怎么实现的。

1. 记录锁

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

2. 间隙锁

第二种情况，当我们查询的记录不存在，没有命中任何一个Record，无论使用的是等值查询还是范围查询，使用的都是间隙锁。
比如where id> 4 and id <7 或者where id = 6
当查询的记录不存在，使用的是间隙锁，间隙锁主要是阻塞插入insert，相同的间隙锁不冲突。
Gap Lock 只在 RR 中存在。如果要关闭间隙锁，就是把事务隔离级别设置成 RC，并且把 innodb_locks_unsafe_for_binlog 设置为 ON

3. 临键锁

第三种情况，我们使用范围查询，不仅仅命中Record，还包含了Gap，这种情况使用的是临键锁，它是MySQL默认的行锁算法。
有两种特殊情况
唯一性索引，等值查询匹配到一条记录时候，退化成记录锁。
没有匹配到任何内容，退化到间隙锁。
临键锁，锁住了key的下一个左开右闭的区间，就是为了解决幻读的问题。

4. 隔离级别的实现

1. Read Uncommited：RU，不加锁
2. Read Commited：RC，普通的select是快照读取，使用MVCC实现，加锁的select使用记录锁
3. Repeatable Read：RR，普通的select使用快照读取，底层采用MVCC，加锁的select（select …in share mode / select …for update）以及update，delete使用当前读（current read），底层采用记录锁，或者间隙锁，临键锁
4. Serializable：Serializable 所有的 select 语句都会被隐式的转化为 select … in share mode，会和 update、delete 互斥

排它锁有互斥的特性，一个事务持有锁的时候，会阻止其他的线程获取锁，这个时候会造成线程阻塞，如果循环等待，有可能会死锁。
有几个问题，锁为什么不释放？？？被阻塞了怎么办？？？死锁是怎么发生的？？？怎么避免？？？

五、死锁

1. 锁的释放和阻塞

锁什么时候释放？
事务结束（commit / rollback），断开连接
如果一个事务一直没有释放锁，其他的事务会被阻塞多久？会不会永远等待下去？
如果是，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库
MySQL有个参数控制获取锁的等待时间，默认是50秒

show VARIABLES like ‘innodb_lock_wait_timeout’;

2. 死锁的发生和检测

死锁的发生条件
因为锁本身是互斥的，所以

1. 同一时刻只能有一个事务持有这个锁
2. 其他的事务需要在这个事务释放锁之后才能获取锁，而不能强行获取
3. 当多个事务形成一个循环回路时，就发生死锁

如果锁一直没有释放，就有可能造成大量阻塞或者发生死锁，造成系统吞吐量下降，这时候就要查看是哪些事务持有了锁。InnoDB 一般能通过算法（wait-for graph）自动检测到是否死锁

3. 查看锁的信息

可以通过show status查看锁的信息
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; – 锁等待的对应关系
这些表都是MySQL数据库默认的表。
找出持有锁的事务之后呢？
如果一个事务长时间持有锁不释放，可以 kill 事务对应的线程 ID，也就是
INNODB_TRX 表中的 trx_mysql_thread_id，例如执行 kill 4，kill 7，kill 8

但是这种方法治标不治本，我们应该尽量去避免死锁

4. 死锁的避免

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

以上就是对MySQL事务和锁的一个大概讲解，如果其中有错误的地方，欢迎指出。如果对你有所帮助，欢迎评论关注。

小白一个，还在继续学习中。。。。。