【MySQL 读书笔记】全局锁 | 表锁 | 行锁

全局锁

全局锁是针对数据库实例的直接加锁,MySQL 提供了一个加全局锁的方法, Flush tables with read lock 可以使用锁将整个表的增删改操作都锁上其中包括 ddl 语句,只允许全局读操作。

全局锁的典型使用场景是做全库的逻辑备份。

不过现在使用官方自带工具 mysqldump 使用参数 --single-transaction 的时候,导出数据之前就会启动一个事务。来确保拿到一致性视图。这个应该类似于在可重复读隔离级别下启动一个一致性事务。由于 MVCC 的支持,这个过程中数据可以正常更新。

另外提一点不太容易遇到的, --single-transaction 既然可以不用锁表,为什么还需要使用全局锁?原因是 --single-transaction 的时候需要支持一致性读,但是不支持事务的引擎是不支持一致性读的。这个时候就需要 FTWRL 命令了。

还有另外一种方法用来支持设置数据库为只读状态

set global readonly=true

这里 丁奇 不建议这样设置来设置数据库为只读有两个原因

一是,在有些系统中,readonly 的值会被用来做其他逻辑,比如用来判断一个库是主库还是备库。因此,修改 global 变量的方式影响面更大,我不建议你使用。

二是,在异常处理机制上有差异。如果执行 FTWRL 命令之后由于客户端发生异常断开,那么 MySQL 会自动释放这个全局锁,整个库回到可以正常更新的状态。而将整个库设置为 readonly 之后,如果客户端发生异常,则数据库就会一直保持 readonly 状态,这样会导致整个库长时间处于不可写状态,风险较高。

表级锁

MySQL 中表级别锁有两种:一种是普通表锁,一种是元数据锁(metadata lock. MDL)

表锁的语法是 lock tables xxx read/write 同样使用 unlock tables 来释放锁。通过加读锁我们可以限制其他语句进行写入,但是重复加读锁不受影响。但是当我们加写锁的时候,既不可以读也不可以写。同样在使用 unlock tables 之后可以解除锁定。

另外一种表级锁是 MDL 锁(metadata lock) MDL 锁不需要显示的使用,在访问一个表的时候自动就被加上了。 MDL 锁是用来保证读写正确性的,当我们对一个表在做 增删改查操作的时候都会被加上 MDL 读锁。当要进行 ddl 的时候需要加 MDL 写锁。

MDL 读锁与读锁之间不互斥,因此我们可以多个线程进程对一个表进行增删改查。

MDL 读写锁之间互斥,用来保证表结构变更的安全性。因此如果有两个线程同时要给同一个表加字段,其中一个要等另外一个执行完成之后再开始执行。

下面我们来看一个比较有代表性的场景 MDL 读锁写锁互斥导致表无法读写被死锁。

【MySQL 读书笔记】全局锁 | 表锁 | 行锁

session A: 开始一个事务,然后查询 t 表,这会给 t 表加上 MDL 读锁。(注意该事务被打开后就一直没有结束)

session B: 查询一个 t 表。这里应该是 autoocommit 会自动成功。

session C: 修改表 ddl 会加 MDL 写锁,和 session A 的读锁互斥。这个时候就锁住了表。

session D: 由于 session C 造成了写锁阻塞,所以后面所有的请求都会被锁住。

如果该表查询频繁,而且客户端有重试的机制,那么这个数据库的查询线程会很快被打满。

可能在进行 web 开发的同学会经常遇到类似的情况。比如我在 ipython 里面打开了一个数据库某个表的连接,然后我一直没有 commit 。就可能造成该表在加写锁的时候阻塞后面所有的操作。

这种事情非常常见。

那么我们如何安全的给小表加字段,首先我们应该解决长事务或者脚本事务的问题,因为他们会一直挂读锁不结束。在 MySQL 的 information_schema 中的 innodb_trx 中可以查询到执行中的长事务,但是比较麻烦的是这个看不到很短的事务。但是往往进行 sleep 的短事务也可能因为一直没有 commit 而导致上面的情况出现。

这个时候就需要把对应表的 sleep 进程 kill 掉使其恢复正常。

行级锁

先来看个描述两阶段锁的例子:

【MySQL 读书笔记】全局锁 | 表锁 | 行锁

事务 A 会持有两条记录的行锁,并且只会在 commit 之后才会释放。

在 InnoDB 事务中,行锁是在需要的时候加上,但是并不是不需要就立刻释放,而是等事务结束之后才会释放。这个就是两阶段锁协议。

知道了这个设定我们应该在长事务中把影响并发度的锁尽量往后放。下面的这一段的介绍比较复杂,我觉得 丁奇 讲得还是比较清楚的所以直接引用原文了。

假设你负责实现一个电影票在线交易业务,顾客 A 要在影院 B 购买电影票。我们简化一点,这个业务需要涉及到以下操作:

1. 从顾客 A 账户余额中扣除电影票价;

2. 给影院 B 的账户余额增加这张电影票价;

3. 记录一条交易日志。

也就是说,要完成这个交易,我们需要 update 两条记录,并 insert 一条记录。当然,为了保证交易的原子性,我们要把这三个操作放在一个事务中。那么,你会怎样安排这三个语句在事务中的顺序呢?

试想如果同时有另外一个顾客 C 要在影院 B 买票,那么这两个事务冲突的部分就是语句 2 了。因为它们要更新同一个影院账户的余额,需要修改同一行数据。

根据两阶段锁协议,不论你怎样安排语句顺序,所有的操作需要的行锁都是在事务提交的时候才释放的。所以,如果你把语句 2 安排在最后,比如按照 3、1、2 这样的顺序,那么影院账户余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待,提升了并发度。

死锁和死锁检测

如果出现下面的不慎操作就会发生死锁。

【MySQL 读书笔记】全局锁 | 表锁 | 行锁

事务 A 开启事务,并且拿了 id = 1 的行锁。

事务 B 开启事务,拿到 id = 2 的行锁。

事务 A 试图去拿 id = 2 的行锁被 block。

事务 B 试图去拿 id = 1 的行锁被 block。

解决死锁 MySQL 目前有两种策略,第二种策略的参数我没有在 MySQL 5.6 版本中找到,在 MySQL 5.7 中找到。

1. 一种策略是,直接进入等待,直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。这个参数默认是 50s。

2. 另一种策略是,发起死锁检测,发现死锁后,主动回滚死锁链条中的某一个事务,让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on,表示开启这个逻辑。

很显然,等待 50 s 失效在现实业务中是不切实际的。肯定会造成高并发的业务大量的阻塞和 500 。所以看上去我们可以依赖第二种办法?

但是第二种办法也有副作用。

死锁检测会对每个新来的被堵住的线程,都判断会不会由于自己的加入导致了死锁,这是一个时间复杂度是 O(n) 的操作。假设有 1000 个并发线程要同时更新同一行,那么死锁检测操作就是 100 万这个量级的。虽然最终检测的结果是没有死锁,但是这期间要消耗大量的 CPU 资源。因此,你就会看到 CPU 利用率很高,但是每秒却执行不了几个事务。

解决这个的方法是

1. 如果我们能确保业务中就是不会存在死锁的逻辑,那么我们可以关闭死锁检测。

2. 我们控制并发度,不让某些业务更新这么快。对客户端的并发控制下来之后,死锁检测的效率是高的,也可以解决这个问题。

Reference:

本读书笔记皆来自发布在极客时间的 林晓斌(丁奇)的 MySQL 实战45讲:

极客时间版权所有: https://time.geekbang.org/ 版权所有:

https://time.geekbang.org/column/article/69862

https://time.geekbang.org/column/article/70215

上一篇:Entity Framework 支持 DataTable


下一篇:【MySQL 读书笔记】当我们在执行该查询语句的时候我们在干什么