全局锁、表级锁、行级锁

锁的作用和特点

WHY：锁的出现是为了解决并发场景下不同用户同时对共享资源进行操作，而可能引发的并发问题。

HOW：控制不同线程对资源访问的规则。

全局锁

顾名思义，全局锁就是对整个数据库实例加锁。一般在进行全库备份的时候会用到。

下面提供几种给 MySQL 数据库添加全局锁的方式：

方式一：采用 Flush tables with read lock (FTWRL) 命令，在这期间，整个数据库都会处于只读状态，其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。由于这种做法会使得整个库都处于只读状态，可能会带来业务停摆和主从延迟的问题。

方式二 （推荐）：用官方自带的逻辑备份工具 mysqlddump。实现可重复读隔离级别下进行数据备份，且由于 MVCC 的支持，这个过程中数据是可以正常更新的。自然，这种方式需要备份的库中的表都是支持事务的（比如 InnoDb）。

方式三：使用 set global readonly=true 命令，一般不建议采用这种方式。主要原因如下：一是，在有些系统中，readonly 的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。二是，在异常处理机制上有差异。如果执行 FTWRL 命令之后由于客户端发生异常断开，那么 MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为 readonly 之后，如果客户端发生异常，则数据库就会一直保持 readonly 状态，这样会导致整个库长时间处于不可写状态，风险较高。

表级锁

MySQL 中的表级锁分为两种：一种是通过执行 sql 语句来为某个表添加表级锁，另一种是元数据锁（meta data lock，MDL)。

方法一：主动添加表锁

主动添加表锁的语法是 lock tables … read/write。与 FTWRL 类似，可以用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。需要注意，lock tables 语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。

举个例子, 如果在某个线程 A 中执行 lock tables t1 read, t2 write; 这个语句，则其他线程写 t1、读写 t2 的语句都会被阻塞。同时，线程 A 在执行 unlock tables 之前，也只能执行读 t1、读写 t2 的操作。连写 t1 都不允许，自然也不能访问其他表。

即：

• 对表加读锁时，其他线程只能读。
• 对表加写锁时，其他线程读写都不行。

在还没有出现更细粒度的锁的时候，表锁是最常用的处理并发的方式。而对于 InnoDB 这种支持行锁的引擎，一般不使用 lock tables 命令来控制并发，毕竟锁住整个表的影响面还是太大。

方法二：元数据锁（meta data lock，MDL)

MDL 不需要显式使用，在访问一个表的时候会被自动加上。MDL 的作用是，保证读写的正确性。你可以想象一下，如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询得到的结果集中可能部分行有 10 列，而另一部分却有 11 列。

因此，在 MySQL 5.5 版本中引入了 MDL，**当对一个表做增删改查操作的时候，加 MDL 读锁；当要对表做结构变更操作的时候，加 MDL 写锁：

• 读锁之间不互斥（与方法一不同），因此你可以有多个线程同时对一张表增删改查。
• 读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。

虽然 MDL 锁是系统默认会加的，但却是你不能忽略的一个机制。比如下面这个例子：给一个小表加个字段，却导致整个库挂了。

会话和事务的理解：会话（Session）指一次数据库连接。事务是指一个操作单元，要么成功，要么失败，没有中间状态。一个会话中可以包含多个事务。

原因是 session C 中对表结构进行更改时需要获取 MDL 写锁，但 session A 的 MDL 读锁还没有释放。而我们前面说了，MDL 的读写锁之间是互斥的，因此 session C 获取不到写锁，只能被阻塞。session C 的阻塞，又导致了之后所有增删改查操作的阻塞，等于这个表现在完全不可读写了。之后过来的所有请求都会堆积起来，不断地占用系统资源，导致数据库宕机。

那么，如何安全地给表加字段呢？

方式一：kill 掉长事务。

方式二：做 DDL 操作时，设置等待时间。

行级锁

行级锁的实现基础：MySQL 的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如 MyISAM 引擎就不支持行锁。因此 MyISAM 表只能通过加表级锁来解决并发问题。

行级锁的概念：行锁就是针对数据表中行记录的锁。这很好理解，比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。

在上面的操作中，事务 B 的 update 语句会被阻塞，直到事务 A 执行 commit 之后，事务 B 才能继续执行。

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

知道了这个设定，对我们使用事务有什么帮助呢？那就是，如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。 我给你举个例子。

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

1. 从顾客账户余额中扣除电影票价；
2. 给影院的账户余额增加这张电影票价；
3. 记录一条交易日志。

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

死锁和死锁检测

当并发系统中不同线程出现循环资源依赖，，就会导致这几个线程都进入无限等待的状态，称为死锁。这里用数据库中的行锁举个例子。

这时候，事务 A 在等待事务 B 释放 id=2 的行锁，而事务 B 在等待事务 A 释放 id=1 的行锁。 事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，有两种策略：

• 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
• 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

参考

• 《MySQL 实战 45 讲》