MySQL 锁机制全解析：从锁的分类到并发更新是否阻塞

引言

在并发场景下，数据库需要解决三类核心问题：

数据一致性：不能读到脏数据
并发安全：多个事务同时修改数据时不出错
性能权衡：在一致性和并发性能之间取得平衡

MySQL（准确来说是 InnoDB 存储引擎 ）通过一整套多层次锁机制 来解决这些问题。这些锁并不是"随便加的"，而是紧密围绕 事务隔离级别、索引结构、并发访问模式 设计出来的。

本文将从三个层次展开：

MySQL 有哪些锁？

表锁和行锁到底解决了什么问题？

真实并发场景下，SQL 会不会阻塞？为什么？

一、MySQL 有哪些锁？------三大类锁体系

从作用范围来看，MySQL 的锁可以分为三大类：

全局锁 → 表级锁 → 行级锁

全局锁（Global Lock）

1.1 什么是全局锁？

全局锁会锁住整个数据库实例，使其进入只读状态。

最典型的加锁方式是：

sql 复制代码

FLUSH TABLES WITH READ LOCK;

此时：

所有表都只能读
所有写操作（INSERT / UPDATE / DELETE）都会被阻塞

1.2 全局锁的典型使用场景

逻辑备份

sql 复制代码

mysqldump --single-transaction ...

在早期 MySQL 版本中，为了保证备份过程中数据一致，通常需要加全局读锁。

1.3 全局锁的问题

整库不可写
在线业务几乎不可接受

现在更多使用 MVCC + 一致性快照，避免全局锁

表级锁（Table-level Lock）

表级锁的作用范围是 单张表，开销小，但并发能力有限。

2.1 表锁（Table Lock）

sql 复制代码

LOCK TABLE t_order READ;
LOCK TABLE t_order WRITE;

READ：其他线程可读，不可写
WRITE：其他线程既不可读，也不可写

InnoDB 一般不推荐使用显式表锁

2.2 元数据锁（MDL，Metadata Lock）

MDL 是自动加的锁，很多人"被它坑过，但不知道是它"。

对表进行 CRUD → 加 MDL 读锁
对表进行 DDL（ALTER / DROP） → 加 MDL 写锁

读写互斥！

sql 复制代码

-- 事务 A
SELECT * FROM t_order; -- 持有 MDL 读锁

-- 事务 B
ALTER TABLE t_order ADD COLUMN xxx; -- 等待

线上 DDL 阻塞业务的元凶

2.3 意向锁（Intention Lock）

意向锁是 InnoDB 行锁的"前置声明"，存在于表级别。

意向共享锁（IS）
意向排他锁（IX）

作用：让表锁与行锁能快速判断是否冲突

"我要锁某几行了，你别直接给我整个表上锁"

行级锁（Row-level Lock）

行锁是 InnoDB 的核心竞争力，并发性能的关键。

3.1 记录锁（Record Lock）

锁住 某一条索引记录

S 锁（共享锁）：读
X 锁（排他锁）：写

sql 复制代码

SELECT * FROM t_order WHERE id = 10 LOCK IN SHARE MODE;
UPDATE t_order SET status = 1 WHERE id = 10;

3.2 间隙锁（Gap Lock）

锁住的是 索引区间之间的"空隙"

只存在于 RR（可重复读）隔离级别
目的：防止幻读

sql 复制代码

SELECT * FROM t_order WHERE id BETWEEN 10 AND 20 FOR UPDATE;

锁住 (10, 20) 这个区间，阻止插入新记录

间隙锁之间是兼容的

3.3 临键锁（Next-Key Lock）

Next-Key Lock = Record Lock + Gap Lock

锁住记录本身
同时锁住前面的间隙

这是 InnoDB RR 隔离级别的默认加锁策略

二、表锁和行锁解决了什么问题？

锁类型	解决的问题
表锁	DDL 与 DML 冲突
行锁	并发更新同一行
间隙锁	防止幻读
临键锁	范围查询 + 插入一致性

本质目标只有一个：
在并发环境下，保证事务隔离语义成立

三、并发场景实战分析：到底会不会阻塞？

场景 1：两个事务同时 UPDATE 同一条记录

sql 复制代码

UPDATE t_order SET status = 1 WHERE id = 100;

会阻塞

第一个事务获取 id=100 的 X 锁
第二个事务只能等待

场景 2：更新不同主键的记录

sql 复制代码

-- 事务 A
UPDATE t_order SET status = 1 WHERE id = 100;

-- 事务 B
UPDATE t_order SET status = 1 WHERE id = 200;

不会阻塞

行锁粒度是"记录级"
主键索引精确定位

场景 3：更新主键范围（存在索引）

sql 复制代码

UPDATE t_order SET status = 1 WHERE id BETWEEN 100 AND 200;

加的是 Next-Key Lock
会锁住区间

其他事务在该区间 INSERT 会被阻塞

场景 4：WHERE 条件未命中索引

sql 复制代码

UPDATE t_order SET status = 1 WHERE order_no = 'xxx';

如果 order_no 没有索引

InnoDB 会 全表扫描
锁升级为 锁住大量记录甚至整表

这才是线上"莫名其妙阻塞"的根源

总结

锁不是 SQL 层决定的，而是：

SQL + 索引 + 隔离级别 + 引擎共同作用的结果

关键记忆点

RR 隔离级别 ≠ 只有行锁
Next-Key Lock 是默认策略
无索引 ≈ 放弃行锁优势
MDL 是 DDL 阻塞的幕后黑手

实战建议

所有更新 SQL 必须走索引
范围更新要评估间隙锁影响
线上 DDL 使用 Online DDL
用 show engine innodb status 排查锁等待