当前位置：首页 > news >正文

xiaolin coding 图解 MySQL笔记——锁篇

news 2025/7/10 3:00:59

1. 全局锁是怎么用的？

flush tables with read lock
执行以后，整个数据库就处于只读状态了，这时其他线程执行对数据的增删改操作（insert、delete、update）；对表结构的更改操作（alter table、drop table）都会被阻塞。

unlock tables
释放全局锁，会话断开全局锁会被自动释放。

2. 全局锁应用场景是什么？

全局锁主要用于做全库逻辑备份，这样在备份数据库期间不会出现备份文件数据和预期的不一样。

3. 加全局锁会带来什么缺点？

加全局锁意味着整个数据库都是只读状态，业务不能更新数据，造成业务停滞。

4. 备份数据库数据的时候，使用全局锁会影响业务，那有什么方式可以避免？

如果数据库的引擎支持的事务可重复读的隔离级别，那么在备份数据库之前先开启事务，这样即使其他的事务更新了表数据，也不会影响备份数据库时的 Read View。因此，对于 InnoDB 存储引擎，在使用备份数据库的工具 mysqldump 时加上 -single-transaction 参数，就会在备份数据库前先开启事务。而对于 MyISAM 这种不支持事务的引擎，在备份数据库时就要使用全局锁。

5. MySQL 表级锁有哪些？

MySQL 里面表级别的锁有这几种：

表锁
元数据锁（MDL）
意向锁；
AUTO-INC 锁

6. 表锁

如果想对学生表（t_student）加表锁，可以使用
lock tables t_student read; 表级别读锁（共享锁），阻止其他会话写操作
lock tables t_student write; 表级别写锁（独占锁），阻止其他会话读写操作

表锁除了限制别的线程的读写，也会限制本线程的读写，同时还会限制本线程访问其他表。

InnoDB 实现了颗粒度更细的行级锁，比颗粒度太大的表锁好。

7. 元数据锁

不需要显式使用元数据锁（MDL），当对一张表进行 CRUD 操作时，会自动加上 MDL 读锁，对一张表做结构变更操作的时候，会自动加上 MDL 写锁。

8. MDL 不需要显式调用，那是在什么时候释放的？

MDL 是在事务提交后才会释放，这意味着事务执行期间，MDL 是一直持有的。

那么如果有一个长事务，比如 A 启用了事务但是一直不提交，然后执行了一条 select 语句，这时候加上了 MDL 读锁，然后 B 也执行了 select，此时并不会冲突（因为读），接着 C 修改了表字段，由于 A 一直没有提交，读锁被占用，C 就无法申请到写锁，被阻塞，C 阻塞后，后续有对该表的 select 语句都会被阻塞。因为申请 MDL 锁的操作会形成一个队列，队列中写锁获取优先级高于读锁，所以一旦出现写锁等待，会阻塞后续该表的所有 CRUD 操作。

所以在对表结构变更前，先看看数据库中的长事务是否已经对表加上了读锁，可以考虑 kill 掉这个长事务。

9. 意向锁

在 InnoDB 引擎的表里对某些记录加上共享锁之前，需要先在表级别加上意向共享锁；对某些记录加上独占锁之前，需要先在表级别加上一个意向独占锁。

意向共享锁和意向独占锁是表级锁，不会和行级的共享锁和独占锁之间发生冲突，而且意向锁之间也不会发生冲突，只会和共享、独占表锁发生冲突。

因为如果没有意向锁，需要在记录级别找是否存在独占锁，效率慢，有了意向锁就先在表级别找是否存在独占锁，意向锁是为了快速判断表里是否有记录被加锁。

10. AUTO-INC 锁

表里的主键通常都会设置成自增的，这是通过 AUTO_INCREMENT 属性实现的，AUTO-INC 是插入数据时加的表级别的锁，不是在一个事务提交后才释放，而是在执行完插入语句后就会立即释放。

但是，AUTO-INC 锁在对大量数据进行插入的时候，会影响插入性能，因为另一个事务的插入会被阻塞，所以 InnoDB 存储引擎提供一种轻量级的锁来实现自增，一样也是在插入数据的时候，会为被AUTO_INCREMENT修饰的字段加上轻量级锁，然后给该字段赋值一个自增的值，就把这个轻量级锁释放了，而不需要等待整个插入语句执行完才释放锁。

InnoDB 提供 innodb_autoinc_lock_mode 的系统变量，用来控制选择用 AUTO-INC 锁，还是轻量级锁，为 0 代表采用 AUTO-INC 锁，2 为采用轻量级锁，为 1 是普通 insert 语句自增锁申请后立马释放，批量插入数据语句等语句结束后才释放。

当 innodb_autoinc_lock_mode = 2 时，并且 binlog_format = row，既能提升并发性，又不会出现数据一致性问题。

11. 行级锁

Record Lock 记录锁
Gap Lock 间隙锁
Next-Key Lock 临键锁：Record Lock + Gap Lock 的组合

12. Record Lock

记录锁锁住的是一条记录，而且记录锁是由 S 锁（共享锁）和 X 锁（独占锁）之分的，当 A 事务对某记录加 S 锁，B 也可以对该记录加 S 锁，但不能加 X 锁；A 加 X 锁，B 不能加 S 或 X 锁。

比如 select * from t_test where id = 1 for update;对 t_test 表中 id 为 1 的行加上了record lock。

13. Gap Lock

间隙锁只存在于可重复隔离级别，目的是为了解决可重复读隔离级别下的幻读。

比如表中有范围 id 为（3，5）间隙锁，那么其他事务就无法插入 id = 4 这条记录了，这样就有效防止了幻读。间隙锁目的是防止插入幻影记录，所以间隙锁之间是兼容的，而且 X和S 型间隙锁没有什么区别

14. Next-Key Lock

临键锁锁定一个范围，并且锁定记录本身，临键锁既能保护该记录，又能阻止其他事务将新纪录插入到间隙中，但是临键锁是包含间隙锁和记录锁的，所以存在记录锁的兼容冲突问题。

15. 插入意向锁

一个事务在插入一条记录的时候，需要判断插入位置是否已被其他事务加了间隙锁，如果有插入操作会发生阻塞，直到拥有间隙锁的事务提交，在此期间会生成一个插入意向锁，表明有事务想在某个区间插入新记录，但是现在处于等待状态。插入意向锁并不是意向锁，是一种特殊的间隙锁，属于行级别锁，间隙锁是一个范围，插入意向锁相当于一个点。

16. 什么是死锁？

死锁发生在两个或多个事务在等待对方释放资源以便自己继续执行，但每个事务又持有对方需要的资源，从而导致所有相关事务都无法继续执行的情况。

死锁的四个必要条件为：

互斥条件：资源不能被多个事务同时使用，即一个资源在某一时刻只能由一个事务占用
占有并等待条件：事务已经持有至少一个资源，并且在等待获取其他事务持有的资源
不可剥夺条件：资源不能被强制从事务中剥夺，事务必须在完成时自愿释放资源
循环等待条件：存在一个事务等待环路，其中每个事务都在等待下一个事务所持有的资源

数据库管理系统通常由机制来检测和处理死锁：

死锁检测：DBMS会定期检查事务之间的依赖关系，以发现是否存在死锁。
死锁解决：一旦检测到死锁，DBMS通常会选择一个或多个事务作为牺牲品，通过回滚这些事务来打破死锁循环，释放资源，以便其他事务可以继续执行。
预防和避免：在设计事务和数据库应用时，可以通过采取一些策略来预防或避免死锁的发生，例如：
- 确保所有事务以相同的顺序请求资源。
- 限制事务持有资源的时间。
- 使用超时机制，当事务等待资源超过一定时间后自动放弃。