面试官：MySQL中有哪些锁！

君

苏三2025年07月17日约 4 分钟

大家好，我是君哥。

前言

在双11期间，支付宝数据库集群每秒处理25万笔交易，而支撑这一切的核心技术之一就是MySQL的锁机制。

很多小伙伴在工作中都遇到过这样的场景：

凌晨批量处理数据时系统突然卡死。
高并发场景下出现诡异的死锁报错。
明明只更新一行却导致全表阻塞。

这篇文章跟大家一起聊聊MySQL的8种锁，希望对你会有所帮助。

一、锁的本质：并发控制的基石

1.1 为什么需要锁？

当多个事务同时操作同一数据时，可能引发：

脏读：读到未提交的数据
不可重复读：同事务内两次读取结果不同
幻读：同条件查询出现新记录

锁的作用：通过对数据资源加锁，实现事务的隔离性（ACID中的"I"）

二、锁的分类全景图

2.1 按粒度划分

按粒度划分为：

表锁
页锁
行锁

2.2 按模式划分

锁类型	共享性	典型场景
共享锁(S)	可共享	SELECT ... LOCK IN SHARE MODE
排他锁(X)	独占	UPDATE/DELETE/INSERT
意向共享锁(IS)	表级标记	准备加行级S锁前
意向排他锁(IX)	表级标记	准备加行级X锁前

三、行级锁：高并发的核心战场

3.1 记录锁（Record Lock）

锁定索引记录：

-- 事务A
BEGIN;
SELECT * FROM users WHERE id = 1 FOR UPDATE; -- 对id=1加X锁

-- 事务B（将被阻塞）
UPDATE users SET name = 'Tom' WHERE id = 1;

底层实现：

3.2 间隙锁（Gap Lock）

锁定索引区间（解决幻读）：

假设当前表结构：id主键（当前有id=1,5,10）

BEGIN;
SELECT * FROM users WHERE id BETWEEN 5 AND 10 FOR UPDATE;

-- 阻塞所有[5,10]区间的插入
INSERT INTO users(id) VALUES(6); -- 被阻塞！
INSERT INTO users(id) VALUES(11); -- 成功

锁定范围：

3.3 临键锁（Next-Key Lock）

记录锁+间隙锁组合：

假设当前数据库隔离级别是RR（Repeatable Read）：

BEGIN;
SELECT * FROM users WHERE id > 5 FOR UPDATE; 

-- 阻塞操作
UPDATE users SET name='A' WHERE id=10; -- 记录锁阻塞
INSERT INTO users(id) VALUES(6);     -- 间隙锁阻塞

锁范围示意图：

四、表级锁：全表扫描的保护伞

4.1 表锁（Table Lock）

显式加锁：

LOCKTABLESusers WRITE; -- 获取写锁
-- 执行更新...
UNLOCKTABLES;

隐式加锁（DDL操作自动加锁）：

ALTERTABLEusersADDCOLUMN age INT; -- 自动加表级X锁

4.2 元数据锁（MDL）

保护表结构：

-- 会话A
BEGIN;
SELECT * FROMusers; -- 获取MDL读锁

-- 会话B（被阻塞）
ALTERTABLEusersADDCOLUMN email VARCHAR(255);

等待链：

五、死锁：高并发的终极挑战

5.1 经典死锁场景

-- 事务A
BEGIN;
UPDATE accounts SET balance = balance - 100WHEREid = 1;
UPDATE accounts SET balance = balance + 100WHEREid = 2;

-- 事务B（反向操作）
BEGIN;
UPDATE accounts SET balance = balance - 100WHEREid = 2;
UPDATE accounts SET balance = balance + 100WHEREid = 1;

死锁形成过程：

5.2 死锁检测与解决

自动检测：

SHOWENGINEINNODBSTATUS; 
-- 查看LATEST DETECTED DEADLOCK

手动处理：

// Spring事务重试
@Retryable(maxAttempts = 3, backoff = @Backoff(delay = 100))
@Transactional
publicvoidtransferMoney(Long from, Long to, BigDecimal amount){
// 转账逻辑
}

六、锁监控与优化实战

6.1 锁等待分析

-- 查看锁等待
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;

6.2 索引优化避免全表锁

问题SQL：

UPDATEusersSETstatus=1WHEREnameLIKE'A%'; -- 无索引导致表锁

优化方案：

ALTERTABLEusersADDINDEX idx_name(name); -- 创建索引
UPDATEusersSETstatus=1WHEREnameLIKE'A%'; -- 仅加行锁

6.3 锁超时配置

# my.cnf
[mysqld]
innodb_lock_wait_timeout=50  # 默认50秒

七、不同隔离级别的锁差异

隔离级别	脏读	不可重复读	幻读	锁机制
读未提交(Read Uncommitted)	可能	可能	可能	不加锁
读已提交(Read Committed)	不可能	可能	可能	语句级快照
可重复读(Repeatable Read)	不可能	不可能	可能(*)	临键锁（默认）
串行化(Serializable)	不可能	不可能	不可能	全表锁

InnoDB在RR级别通过Next-Key Lock解决幻读问题。

八、锁机制最佳实践

8.1 锁优化口诀

一快：事务执行要快。
二小：锁粒度尽量小。
三避免：避免大事务、全表扫描、长等待。

8.2 不同场景锁选择

场景	推荐方案
精确更新单行	行级X锁（WHERE主键）
范围更新	Next-Key Lock（RR隔离级别）
全表更新	分批提交+低峰期执行
结构变更	PT-Online-Schema-Change工具

总结

锁是双刃剑：保护数据一致性的同时降低并发度
粒度决定性能：行锁 > 页锁 > 表锁
隔离级别是基础：根据业务选择合适级别（推荐RR）
索引是钥匙：80%的锁问题可通过优化索引解决
监控是眼睛：善用SHOW ENGINE INNODB STATUS

正如数据库专家Michael Stonebraker所言：
“The best locking strategy is no locking at all.”

最高明的锁策略是“无锁”，而这正是我们不断优化的方向。