『 MySQL篇 』：MySQL 锁机制介绍_mysql锁机制

目录

一. 概述

二. 全局锁

三 . 表级锁

三. 行级锁

---

一. 概述

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（CPU、RAM、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

MySQL中的锁按照锁的粒度分，分为一下三类：

• 全局锁：锁定数据库中所有的表。
• 表级锁：每次操作锁住整张表
• 行级锁：每次操作锁住对应的行数据。

二. 全局锁

a. 介绍

全局锁就是对数据库的整个实例加锁， 加锁之后整个实例就处于只读状态，后续的DML写语句，DDL语句，以及更新操作的事务提交语句都会被阻塞，全局锁的典型使用场景就是进行全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。

为什么进行全库备份时候加全局锁呢？

下面我们通过一个简单的例子来介绍一下不加全局锁时，可能出现的问题

假设数据库中存在着三张表 , tb_stock 库存表，tb_order 订单表，tb_orderlog 订单日志表。

在进行数据备份时 :

• 先备份了 tb _ stock 表
• 然后接下来, 在业务系统中,执行了下单操作,扣减库存, 生成订单,(更新 tb_stock 表, 插入 tb _ order 表)
• 然后再执行备份 tb_order 表 的逻辑
• 业务中执行插入订单日志的操作
• 最后 , 备份了 tb_orderlog 表

再上述的执行过程中, 备份出来的数据是存在问题的 , 因为备份出来的数据 , tb_stock 表 和 tb_order 表 存在着数据不一致的问题, 有最新的订单信息 , 但是总的库存数没有发生变化

那如何规避这种数据不一致的现象呢 , 此时就需要借助 MySQL 的全局锁来解决:

此时 , 我们再来分析一下加了全局锁之后的情况:

在进行数据库的逻辑备份之前, 先对数据库加上全局锁,一旦加上全局锁之后,其他的DDL,DML全部都处于阻塞状态,

但是可以执行DQL语句,也就是只读状态,而数据备份就是查询操作, 那么在数据备份的过程中 , 数据库中的数据是不会发生变化的,这样就保证了数据的完整性和一致性.

b. 操作

• 加全局锁

flush tables with read lock;

• 数据备份

mysqldump -uroot –p1234 itcast > itcast.sql

• 释放锁

unlock tables;

c. 特点

数据库中如果加全局锁 , 是一个粒度比较重的操作, 容易存在以下问题:

• 如果在主库上进行备份,那么在备份期间都不能执行更新操作,业务基本就处于停摆
• 如果在从库上进行备份,那么在备份期间,从库不能执行主库同步过来的二进制文件 ,就会导致主从延迟.

在 InnoDB 引擎中, 可以通过备份时增加一个参数来完成不加锁的数据一致性备份

mysqldump --single-transaction -uroot –p123456 itcast > itcast.sql

三 . 表级锁

表级锁 , 顾名思义,每次操作能够锁住整张表, 锁定粒度大,发生锁冲突概率较高,并发度最低 , 通常应用在 InnoDB , MyISAM, BDB 等引擎当中, 此处我们只对 InnoDB 中的表级锁进行详解:

1. 表锁

对于表级锁, 主要分为以下三类:

1. 表锁
2. 元数据锁
3. 意向锁

对于表锁 , 主要分为两类

1. 表共享读锁(read lock )

特点 : 对指定表加了读锁之后,当客户端一进行读操作时,不会影响客户端二的读,但是都会阻塞两哥客户端的写操作.

1. 表独占写锁(write lock)

针对指定表增加了独占写锁之后, 客户端一可以针对表进行读和写, 而客户端二的读和写就会被阻塞

语法：

• 加锁：lock tables 表名... read/write。
• 释放锁：unlock tables / 客户端断开连接 。

总结: 读锁不会阻塞其他客户端的读 , 但是会阻塞写 , 写锁既会阻塞其他客户端的读,又会阻塞其他客户端的写。

2. 元数据锁

元数据锁，简写MDL。MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与DDL冲突，保证读写的正确性。

这里的元数据，大家可以简单理解为就是一张表的表结构。 也就是说，某一张表涉及到未提交的事务时，是不能够修改这张表的表结构的。

在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁(共享)；当对表结构进行变更操作的时候，加MDL写锁(排他)。

那如果数据库有一个长事务（所谓的长事务，就是开启了事务，但是一直还没提交），那在对表结构做变更操作的时候，可能会发生意想不到的事情，比如下面这个顺序的场景：

1. 首先，线程 A 先启用了事务（但是一直不提交），然后执行一条 select 语句，此时就先对该表加上 MDL 读锁；
2. 然后，线程 B 也执行了同样的 select 语句，此时并不会阻塞，因为「读读」并不冲突；
3. 接着，线程 C 修改了表字段，此时由于线程 A 的事务并没有提交，也就是 MDL 读锁还在占用着，这时线程 C 就无法申请到 MDL 写锁，就会被阻塞，
4. 那么在线程 C 阻塞后，后续有对该表的 select 语句，就都会被阻塞，如果此时有大量该表的 select 语句的请求到来，就会有大量的线程被阻塞住，这时数据库的线程很快就会爆满了。

这是因为申请 MDL 锁的操作会形成一个队列，队列中写锁获取优先级高于读锁，一旦出现 MDL 写锁等待，会阻塞后续该表的所有 CRUD 操作。

共享锁：允许多个事务同时持有该锁，用于读取数据时，避免其他事务对数据进行修改。共享锁不会阻塞其他事务的共享锁请求，但会阻塞其他事务的独占锁和排他锁请求。

独占锁：只允许一个事务持有该锁，用于修改数据时，防止其他事务同时修改同一数据。独占锁会阻塞其他事务的共享锁和独占锁请求，但不会阻塞其他事务的排他锁请求。

排他锁：只允许一个事务持有该锁，用于修改数据时，防止其他事务同时修改同一数据。排他锁会阻塞所有其他事务的锁请求，包括共享锁、独占锁和排他锁。

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

• 操作

查看元数据锁的加锁情况

mysql> select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks;
+-------------+--------------------+----------------+--------------+---------------+
| object_type | object_schema      | object_name    | lock_type    | lock_duration |
+-------------+--------------------+----------------+--------------+---------------+
| TABLE       | MySQL_Advanced     | tb_user        | SHARED_READ  | TRANSACTION   |
| TABLE       | MySQL_Advanced     | tb_user        | SHARED_READ  | TRANSACTION   |
| TABLE       | MySQL_Advanced     | tb_user        | SHARED_WRITE | TRANSACTION   |
| TABLE       | MySQL_Advanced     | user_logs      | SHARED_WRITE | TRANSACTION   |
| TABLE       | performance_schema | metadata_locks | SHARED_READ  | TRANSACTION   |
+-------------+--------------------+----------------+--------------+---------------+
5 rows in set (0.00 sec)

3. 意向锁

1. 介绍

为了避免在DML进行执行时, 加的行锁与表锁相互冲突, 在 InnoDB 引擎中引入了意向锁, 使得表锁不需要去检查每行是否加锁 .

假如没有意向锁的情况下 , 客户端 一对表加了行锁之后, 客户端二如何给表进行加锁呢?

首先, 客户端一 , 开启一个事务, 然后执行 DML 操作, 在执行DML语句时, 会对涉及到的行进行加行锁.

当客户端二想要对这张表进行加表锁时,会检查当前表是否有对应的行锁,如果没有,则添加表锁,此时就会从第一行数据检查到最后一行 , 效率较低.

有了意向锁之后, 在执行DML操作时,会对涉及的行加上行锁,同时也会给该表加上意向锁.

而其他客户端对该表进行加表锁时,就可以根据是否存在意向锁来判断是否可以成功加锁.

1. 分类

• 意向共享锁 : 与表锁共享锁兼容, 与表锁排他锁互斥
• 意向排他锁: 与表锁排他锁和表锁共享锁都互斥

意向共享锁和意向独占锁是表级锁，不会和行级的共享锁和独占锁发生冲突，而且意向锁之间也不会发生冲突，只会和共享表锁（lock tables ... read）和独占表锁（lock tables ... write）发生冲突。

一旦事务提交了, 意向共享锁与意向排他锁都会释放

执行插入、更新、删除操作，需要先对表加上「意向独占锁」，然后对该记录加独占锁 , 这样就可以快速判断表中是否有记录加锁.

三. 行级锁

每次操作锁住对应的行数据，锁定的粒度最小，发生锁冲突的概率最低，并发度最高，应用在InnoDB 引擎中

InnoDB 引擎与 MySlAM 引擎的三大区别：事务 外键 行锁

对于行级锁 ， 主要分为以下三类：

1. 行锁（Record Lock）：锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。

InnoDB中实现了以下两种类型的行锁：

• 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁
• 排他锁（X）：允许排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。

两种行锁的兼容情况如下：

-- 会话 1
BEGIN;
SELECT * FROM orders WHERE id = 1 FOR UPDATE;
-- 对 id=1 的数据行进行修改
UPDATE orders SET amount = amount + 100 WHERE id = 1;
COMMIT;
 
-- 会话 2
BEGIN;
-- 因为会话 1 对 id=1 的数据行进行了行锁，所以会话 2 不能同时对该行进行修改，
-- 如果执行下面的语句会一直等待会话 1 的事务提交或回滚
UPDATE orders SET amount = amount - 50 WHERE id = 1;

1. 间隙锁

间隙锁：指对一个索引范围中的“空隙”进行锁定，防止其他事务在这个范围内插入新数据。间隙锁用于解决幻读问题。

例如在某个事务中执行了一个范围查询，然后在范围内的间隙处插入了新数据，这时再次执行相同的查询，会发现有一些行出现了两次，这就是幻读。通过间隙锁，可以防止其他事务插入新的数据，从而避免幻读。

假设，表中有一个范围 id 为（3，5）间隙锁，那么其他事务就无法插入 id = 4 这条记录了，这样就有效的防止幻读现象的发生。

-- 会话 1
BEGIN;
-- 对 id 大于 1 小于 10 的范围进行间隙锁定
SELECT * FROM orders WHERE id > 1 AND id < 10 FOR UPDATE;
-- 间隙锁会阻止其他事务在 id 大于 1 小于 10 的范围内插入数据，
-- 但允许其他事务在该范围之外的位置插入数据
COMMIT;
 
-- 会话 2
BEGIN;
-- 因为会话 1 对 id 大于 1 小于 10 的范围进行了间隙锁定，所以会话 2 不能在该范围内插入数据，
-- 如果执行下面的语句会一直等待会话 1 的事务提交或回滚
INSERT INTO orders (id, amount) VALUES (5, 500);

1. 临键锁

临键锁与间隙锁的不同之处在于，他所锁定的不只是一个范围，还包括了锁定记录本身。

• 索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，临键锁退化为间隙锁。

假设，表中有一个范围 id 为（3，5] 的 next-key lock，那么其他事务即不能插入 id = 4 记录，也不能修改 id = 5 这条记录。

所以，临键锁即能保护该记录，又能阻止其他事务将新纪录插入到被保护记录前面的间隙中。

临键锁之间的X，S锁之间的互斥关系同样遵循行锁之间的互斥关系。

• 总结：

在 InnoDB 中，默认情况下是使用行锁实现事务隔离级别的。当需要锁定一整张表时，可以使用表锁；当需要解决幻读问题时，可以使用间隙锁。在使用间隙锁时，需要注意锁的范围，避免影响其他事务的正常操作。