MySQL面试常问问题（锁 + 事务） —— 赶快收藏
目录
1.MySQL中有哪几种锁，列举一下？
2.说说InnoDB里的行锁实现?
3.意向锁是什么知道吗？
4.MySQL的乐观锁和悲观锁了解吗？
5.MySQL 遇到过死锁问题吗，你是如何解决的？
6.MySQL 事务的四大特性说一下？
7.那ACID靠什么保证的呢？
8.事务的隔离级别有哪些？MySQL 的默认隔离级别是什么？
9.什么是幻读，脏读，不可重复读呢？
10.事务的各个隔离级别都是如何实现的？
11.MVCC了解吗？怎么实现的？
1.MySQL中有哪几种锁，列举一下？
MySQL中的锁
如果按锁粒度划分，有以下3种：
-
表锁：开销小，加锁快；锁定力度大，发生锁冲突概率高，并发度最低;不会出现死锁。
-
行锁：开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高。
-
页锁：开销和加锁速度介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般
如果按照兼容性，有两种，
-
共享锁（S Lock）,也叫读锁（read lock），相互不阻塞。
-
排他锁（X Lock），也叫写锁（write lock），排它锁是阻塞的，在一定时间内，只有一个请求能执行写入，并阻止其它锁读取正在写入的数据。
2.说说InnoDB里的行锁实现?
我们拿这么一个用户表来表示行级锁，其中插入了4行数据，主键值分别是1,6,8,12，现在简化它的聚簇索引结构，只保留数据记录。
简化的主键索引
InnoDB的行锁的主要实现如下：
-
Record Lock 记录锁
记录锁就是直接锁定某行记录。当我们使用唯一性的索引(包括唯一索引和聚簇索引)进行等值查询且精准匹配到一条记录时，此时就会直接将这条记录锁定。例如select * from t where id =6 for update;就会将id=6的记录锁定。
记录锁
-
Gap Lock 间隙锁
间隙锁(Gap Locks) 的间隙指的是两个记录之间逻辑上尚未填入数据的部分,是一个左开右开空间。
间隙锁
间隙锁就是锁定某些间隙区间的。当我们使用用等值查询或者范围查询，并且没有命中任何一个record，此时就会将对应的间隙区间锁定。例如select * from t where id =3 for update;或者select * from t where id > 1 and id < 6 for update;就会将(1,6)区间锁定。
-
Next-key Lock 临键锁
临键指的是间隙加上它右边的记录组成的左开右闭区间。比如上述的(1,6]、(6,8]等。
临键锁
临键锁就是记录锁(Record Locks)和间隙锁(Gap Locks)的结合，即除了锁住记录本身，还要再锁住索引之间的间隙。当我们使用范围查询，并且命中了部分record记录，此时锁住的就是临键区间。注意，临键锁锁住的区间会包含最后一个record的右边的临键区间。例如select * from t where id > 5 and id <= 7 for update;会锁住(4,7]、(7,+∞)。mysql默认行锁类型就是临键锁(Next-Key Locks)。当使用唯一性索引，等值查询匹配到一条记录的时候，临键锁(Next-Key Locks)会退化成记录锁；没有匹配到任何记录的时候，退化成间隙锁。
间隙锁(Gap Locks)和临键锁(Next-Key Locks)都是用来解决幻读问题的，在已提交读（READ COMMITTED）隔离级别下，间隙锁(Gap Locks)和临键锁(Next-Key Locks)都会失效！
上面是行锁的三种实现算法，除此之外，在行上还存在插入意向锁。
-
Insert Intention Lock 插入意向锁
一个事务在插入一条记录时需要判断一下插入位置是不是被别的事务加了意向锁 ，如果有的话，插入操作需要等待，直到拥有 gap锁 的那个事务提交。但是事务在等待的时候也需要在内存中生成一个 锁结构 ，表明有事务想在某个 间隙 中插入新记录，但是现在在等待。这种类型的锁命名为 Insert Intention Locks ，也就是插入意向锁 。
假如我们有个T1事务，给(1,6)区间加上了意向锁，现在有个T2事务，要插入一个数据，id为4，它会获取一个（1,6）区间的插入意向锁，又有有个T3事务，想要插入一个数据，id为3，它也会获取一个（1,6）区间的插入意向锁，但是，这两个插入意向锁锁不会互斥。
插入意向锁
3.意向锁是什么知道吗？
意向锁是一个表级锁，不要和插入意向锁搞混。
意向锁的出现是为了支持InnoDB的多粒度锁，它解决的是表锁和行锁共存的问题。
当我们需要给一个表加表锁的时候，我们需要根据去判断表中有没有数据行被锁定，以确定是否能加成功。
假如没有意向锁，那么我们就得遍历表中所有数据行来判断有没有行锁；
有了意向锁这个表级锁之后，则我们直接判断一次就知道表中是否有数据行被锁定了。
有了意向锁之后，要执行的事务A在申请行锁（写锁）之前，数据库会自动先给事务A申请表的意向排他锁。当事务B去申请表的互斥锁时就会失败，因为表上有意向排他锁之后事务B申请表的互斥锁时会被阻塞。
意向锁
4.MySQL的乐观锁和悲观锁了解吗？
-
悲观锁（Pessimistic Concurrency Control）：
悲观锁认为被它保护的数据是极其不安全的，每时每刻都有可能被改动，一个事务拿到悲观锁后，其他任何事务都不能对该数据进行修改，只能等待锁被释放才可以执行。
数据库中的行锁，表锁，读锁，写锁均为悲观锁。
-
乐观锁（Optimistic Concurrency Control）
乐观锁认为数据的变动不会太频繁。
乐观锁通常是通过在表中增加一个版本(version)或时间戳(timestamp)来实现，其中，版本最为常用。
事务在从数据库中取数据时，会将该数据的版本也取出来(v1)，当事务对数据变动完毕想要将其更新到表中时，会将之前取出的版本v1与数据中最新的版本v2相对比，如果v1=v2，那么说明在数据变动期间，没有其他事务对数据进行修改，此时，就允许事务对表中的数据进行修改，并且修改时version会加1，以此来表明数据已被变动。
如果，v1不等于v2，那么说明数据变动期间，数据被其他事务改动了，此时不允许数据更新到表中，一般的处理办法是通知用户让其重新操作。不同于悲观锁，乐观锁通常是由开发者实现的。
5.MySQL 遇到过死锁问题吗，你是如何解决的？
排查死锁的一般步骤是这样的：
（1）查看死锁日志 show engine innodb status;
（2）找出死锁 sql
（3）分析 sql 加锁情况
（4）模拟死锁案发
（5）分析死锁日志
（6）分析死锁结果
当然，这只是一个简单的流程说明，实际上生产中的死锁千奇百怪，排查和解决起来没那么简单。
6.MySQL 事务的四大特性说一下？
事务四大特性
-
原子性：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
-
一致性：指在事务开始之前和事务结束以后，数据不会被破坏，假如 A 账户给 B 账户转 10 块钱，不管成功与否，A 和 B 的总金额是不变的。
-
隔离性：多个事务并发访问时，事务之间是相互隔离的，即一个事务不影响其它事务运行效果。简言之，就是事务之间是进水不犯河水的。
-
持久性：表示事务完成以后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。
7.那ACID靠什么保证的呢？
-
事务的隔离性是通过数据库锁的机制实现的。
-
事务的一致性由undo log来保证：undo log是逻辑日志，记录了事务的insert、update、deltete操作，回滚的时候做相反的delete、update、insert操作来恢复数据。
-
事务的原子性和持久性由redo log来保证：redolog被称作重做日志，是物理日志，事务提交的时候，必须先将事务的所有日志写入redo log持久化，到事务的提交操作才算完成。
ACID靠什么保证
8.事务的隔离级别有哪些？MySQL 的默认隔离级别是什么？
事务的四个隔离级别
-
读未提交（Read Uncommitted）
-
读已提交（Read Committed）
-
可重复读（Repeatable Read）
-
串行化（Serializable）
MySQL默认的事务隔离级别是可重复读 (Repeatable Read)。
9.什么是幻读，脏读，不可重复读呢？
-
事务 A、B 交替执行，事务 A 读取到事务 B 未提交的数据，这就是脏读。
-
在一个事务范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。
-
事务 A 查询一个范围的结果集，另一个并发事务 B 往这个范围中插入 / 删除了数据，并静悄悄地提交，然后事务 A 再次查询相同的范围，两次读取得到的结果集不一样了，这就是幻读。
不同的隔离级别，在并发事务下可能会发生的问题：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| Read Uncommited 读取未提交 | 是 | 是 | 是 |
| Read Commited 读取已提交 | 否 | 是 | 否 |
| Repeatable Read 可重复读 | 否 | 否 | 是 |
| Serialzable 可串行化 | 否 | 否 | 否 |
10.事务的各个隔离级别都是如何实现的？
读未提交
读未提交，就不用多说了，采取的是读不加锁原理。
-
事务读不加锁，不阻塞其他事务的读和写
-
事务写阻塞其他事务写，但不阻塞其他事务读；
读取已提交&可重复读
读取已提交和可重复读级别利用了ReadView和MVCC，也就是每个事务只能读取它能看到的版本（ReadView）。
-
READ COMMITTED：每次读取数据前都生成一个ReadView
-
REPEATABLE READ ：在第一次读取数据时生成一个ReadView
串行化
串行化的实现采用的是读写都加锁的原理。
串行化的情况下，对于同一行事务，写会加写锁，读会加读锁。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。
11.MVCC了解吗？怎么实现的？
MVCC(Multi Version Concurrency Control)，中文名是多版本并发控制，简单来说就是通过维护数据历史版本，从而解决并发访问情况下的读一致性问题。关于它的实现，要抓住几个关键点，隐式字段、undo日志、版本链、快照读&当前读、Read View。
版本链
对于InnoDB存储引擎，每一行记录都有两个隐藏列DB_TRX_ID、DB_ROLL_PTR
-
DB_TRX_ID，事务ID，每次修改时，都会把该事务ID复制给DB_TRX_ID； -
DB_ROLL_PTR，回滚指针，指向回滚段的undo日志。
表隐藏列
假如有一张user表，表中只有一行记录，当时插入的事务id为80。此时，该条记录的示例图如下：
在这里插入图片描述
接下来有两个DB_TRX_ID分别为100、200的事务对这条记录进行update操作，整个过程如下：
update操作
由于每次变动都会先把undo日志记录下来，并用DB_ROLL_PTR指向undo日志地址。因此可以认为，对该条记录的修改日志串联起来就形成了一个版本链，版本链的头节点就是当前记录最新的值。如下：
MVCC
ReadView
对于
Read Committed和Repeatable Read隔离级别来说，都需要读取已经提交的事务所修改的记录，也就是说如果版本链中某个版本的修改没有提交，那么该版本的记录时不能被读取的。所以需要确定在Read Committed和Repeatable Read隔离级别下，版本链中哪个版本是能被当前事务读取的。于是就引入了ReadView这个概念来解决这个问题。
Read View就是事务执行快照读时，产生的读视图，相当于某时刻表记录的一个快照，通过这个快照，我们可以获取：
事务和ReadView
-
m_ids ：表示在生成 ReadView 时当前系统中活跃的读写事务的事务id 列表。
-
min_trx_id ：表示在生成 ReadView 时当前系统中活跃的读写事务中最小的 事务id ，也就是 m_ids 中的最小值。
-
max_trx_id ：表示生成 ReadView 时系统中应该分配给下一个事务的 id 值。
-
creator_trx_id ：表示生成该 ReadView 的事务的 事务id
有了这个 ReadView ，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：
-
如果被访问版本的 DB_TRX_ID 属性值与 ReadView 中的 creator_trx_id 值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
-
如果被访问版本的 DB_TRX_ID 属性值小于 ReadView 中的 min_trx_id 值，表明生成该版本的事务在当前事务生成 ReadView 前已经提交，所以该版本可以被当前事务访问。
-
如果被访问版本的 DB_TRX_ID 属性值大于 ReadView 中的 max_trx_id 值，表明生成该版本的事务在当前事务生成 ReadView 后才开启，所以该版本不可以被当前事务访问。
-
如果被访问版本的 DB_TRX_ID 属性值在 ReadView 的 min_trx_id 和 max_trx_id 之间，那就需要判断一下trx_id 属性值是不是在 m_ids 列表中，如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。
如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。
在 MySQL 中， READ COMMITTED 和 REPEATABLE READ 隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同。
READ COMMITTED 是每次读取数据前都生成一个ReadView，这样就能保证自己每次都能读到其它事务提交的数据；REPEATABLE READ 是在第一次读取数据时生成一个ReadView，这样就能保证后续读取的结果完全一致。