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

【MySQL实战45讲笔记】基础篇—— 全局锁和表锁

article 2024/11/27 1:26:19

系列文章

基础篇——MySQL 的基础架构
基础篇——redo log 和 binlog
基础篇——事务隔离
基础篇——深入浅出索引（上）
基础篇——深入浅出索引（下）

6.1 全局锁

顾名思义，全局锁就是对整个数据库实例加锁。一般当我们需要让整个库处于只读状态的时候需要全局锁的帮助来阻塞其他线程的DML、DDL语句。全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都 select 出来存成文本。

6.1.1 server级和存储引擎级的全局锁

对于不支持事务的存储引擎比如MyISM，只能在server层手动添加全局锁来实现：Flush tables with read lock (FTWRL)。不过风险是：
- 如果在主库上执行，也就是在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆；
- 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog，会导致主从延迟。因为在只读状态下，从库的SQL线程无法执行binlog中的更新操作。这种情况下，即使I/O线程仍在运行并尝试拉取binlog，从库也无法应用这些binlog，从而导致主从延迟。
对于支持事务的存储引擎比如InnoDB，就可以使用它的特性，通过在可重复读这个隔离级别下开启一个事务，来保证保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。所以全库备份就可以使用官方自带的逻辑备份工具mysqldump，加上–single-transaction参数。

所以还是尽量使用InnoDB代替MyISM吧。

6.1.2 FTWRL VS readonly

另外，既然要全库只读，为什么不使用 set global readonly=true 的方式呢？确实 readonly 方式也可以让全库进入只读状态，但我还是会建议你用 FTWRL 方式，主要有两个原因：

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

6.2 表级锁

MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)。

6.2.1 表锁

表锁的语法是 lock tables … read/write。与 FTWRL 类似，可以用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。

表锁有读锁（共享的）和写锁（独占的）。

如果线程对表加了读锁，那么自己和其他线程可以读取该表，但是都不能对其修改
如果线程对表加了写锁，那么只有自己可以读、写该表，其他线程对该表的读和写都受到阻塞

不过锁住整个表的影响面还是太大，对于InnoDB 这种支持行锁的引擎，一般不使用 lock tables 命令来控制并发

6.2.2 MDL元数据锁

元数据锁也是server层的表级锁，主要用于隔离DML（Data Manipulation Language，数据操纵语言，如对数据的增删改查）和DDL（Data Definition Language，数据定义语言，如改表字段）操作之间的干扰。每执行一条DML、DDL语句时都会申请MDL锁，DML操作需要MDL读锁，DDL操作需要MDL写锁（MDL加锁过程是系统自动控制，无法直接干预，读读共享，读写互斥，写写互斥）

不过MDL有一个不可忽略的机制就是关于锁队列，在DML时会添加MDL读锁，如果这时有一个线程想要进行DDL操作，会申请写锁，这时写锁被阻塞，导致后面即使有想要DML的线程都被阻塞掉了，从客户端角度来看就是一直操作失败，一直超时重试，那么这个库的线程很快就会爆满。

下面是一个例子进行说明，下面是一组操作序列，假设表 t 是一个小表（这里的实验环境是 MySQL 5.6）。

session A 先启动，这时候会对表 t 加一个 MDL 读锁
session B 需要的也是 MDL 读锁，因此可以正常执行
session C 会被 blocked，是因为 session A 的 MDL 读锁还没有释放，而 session C 需要 MDL 写锁，因此只能被阻塞。
如果只有 session C 自己被阻塞还没什么关系，但是之后所有要在表 t 上新申请 MDL 读锁的请求也会被 session C 阻塞。前面我们说了，所有对表的增删改查操作都需要先申请 MDL 读锁，就都被锁住，等于这个表现在完全不可读写了。

如果某个表上的查询语句频繁，而且客户端有重试机制，也就是说超时后会再起一个新 session 再请求的话，这个库的线程很快就会爆满。

现在我们知道了，事务中的 MDL 锁，在语句执行开始时申请，但是语句结束后并不会马上释放，而会等到整个事务提交后再释放。

6.2.3 如何安全地给小表加字段

基于前面的分析：

MDL写锁会阻塞在读锁队列，导致这个表完全不可读写
MDL锁在事务提交或回滚后才会释放。

现在来解决“如何安全地给小表加字段”这个问题：

首先我们要解决长事务，事务不提交，就会一直占着 MDL 锁。在 MySQL 的 information_schema 库的 innodb_trx 表中，你可以查到当前执行中的事务。如果你要做 DDL 变更的表刚好有长事务在执行，要考虑先暂停 DDL，或者 kill 掉这个长事务。
在请求很频繁的时候，即使kill掉，新的请求马上就来了。所以在更改语句中设定等待时间，如果在这个指定的等待时间里面能够拿到 MDL 写锁最好，拿不到也不要阻塞后面的业务语句，先放弃

MariaDB 已经合并了 AliSQL 的这个功能，所以这两个开源分支目前都支持 DDL NOWAIT/WAIT n 这个语法。
```
ALTER TABLE tbl_name NOWAIT add column ...
ALTER TABLE tbl_name WAIT N add column ... 
```

6.3 思考题

当备库用–single-transaction 做逻辑备份的时候，如果从主库的 binlog 传来一个 DDL 语句会怎么样？

假设这个 DDL 是针对表 t1 的，这里我把备份过程中几个关键的语句列出来（这是mysqldump内部的实现，开发人员只需要使用命令就行了）：

Q1:SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Q2:START TRANSACTION  WITH CONSISTENT SNAPSHOT；
/* other tables */
Q3:SAVEPOINT sp;
/* 时刻 1 */
Q4:show create table `t1`;
/* 时刻 2 */
Q5:SELECT * FROM `t1`;
/* 时刻 3 */
Q6:ROLLBACK TO SAVEPOINT sp;
/* 时刻 4 */
/* other tables */

在备份开始的时候，为了确保 RR（可重复读）隔离级别，再设置一次 RR 隔离级别 (Q1);
启动事务，这里用 WITH CONSISTENT SNAPSHOT 确保这个语句执行完就可以得到一个一致性视图（Q2)；
设置一个保存点savepoint，这个很重要（Q3）；这是配合下面的Q6使用的，因为备份过程中会有多个mdl锁，一个表一个（假设有tn个表）如果不设置savepoint，第一个表读完后，表1的dml锁还不会释放，会一直等tn的表读完，事务提交才会释放所有表的锁，所以时间会很长，设置回滚点，读完数据后，回滚释放锁。就能将锁的占用时间控制到最短。
show create 是为了拿到表结构 (Q4)，然后正式导数据（Q5），回滚到 SAVEPOINT sp，在这里的作用是释放 t1 的 MDL 锁（Q6）

DDL 从主库传过来的时间按照效果不同，这里打了四个时刻。题目设定为小表，我们假定到达后，如果开始执行，则很快能够执行完成。

所以这个问题的参考答案如下：

如果在 Q4 语句执行之前到达，现象：没有影响，备份拿到的是 DDL 后的表结构。
如果在“时刻 2”到达，则表结构被改过，Q5 执行的时候，报 Table definition has changed, please retry transaction，现象：mysqldump 终止。
如果在“时刻 2”和“时刻 3”之间到达，mysqldump 占着 t1 的 MDL 读锁，binlog 被阻塞，现象：主从延迟，直到 Q6 执行完成。
从“时刻 4”开始，mysqldump 释放了 MDL 读锁，现象：没有影响，备份拿到的是 DDL 前的表结构。

查看全文

http://www.kler.cn/a/410712.html