MySQL中的八种锁！你知道几种？

前言

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

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

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

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

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

1.为什么需要锁？

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

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

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

二、锁的种道种分类全景图

1.按粒度划分

按粒度划分为：

表锁页锁行锁

2.按模式划分

锁类型

共享性

典型场景

共享锁(S)

可共享

SELECT ... LOCK IN SHARE MODE

排他锁(X)

独占

UPDATE/DELETE/INSERT

意向共享锁(IS)

表级标记

准备加行级S锁前

意向排他锁(IX)

表级标记

准备加行级X锁前

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

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;1.2.3.4.5.6.

底层实现：

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); -- 成功1.2.3.4.5.6.

锁定范围：

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); -- 间隙锁阻塞1.2.3.4.5.6.

锁范围示意图：

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

1.表锁（Table Lock）

显式加锁：

复制LOCK TABLES users WRITE; -- 获取写锁 -- 执行更新... UNLOCK TABLES;1.2.3.

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

复制ALTER TABLE users ADD COLUMN age INT; -- 自动加表级X锁1.

2.元数据锁（MDL）

保护表结构：

复制-- 会话A BEGIN; SELECT * FROM users; -- 获取MDL读锁 -- 会话B（被阻塞） ALTER TABLE users ADD COLUMN email VARCHAR(255);1.2.3.4.5.6.

等待链：

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

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;1.2.3.4.5.6.7.8.9.

死锁形成过程：

2.死锁检测与解决

自动检测：

复制SHOW ENGINE INNODB STATUS; -- 查看LATEST DETECTED DEADLOCK1.2.

手动处理：

复制// Spring事务重试 @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 100)) @Transactional public void transferMoney(Long from, Long to, BigDecimal amount) { // 转账逻辑 }1.2.3.4.5.6.

六、锁监控与优化实战

1.锁等待分析

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

2.索引优化避免全表锁

问题SQL：

复制UPDATE users SET status=1 WHERE name LIKE A%; -- 无索引导致表锁1.

优化方案：

复制ALTER TABLE users ADD INDEX idx_name(name); -- 创建索引 UPDATE users SET status=1 WHERE name LIKE A%; -- 仅加行锁1.2.

3.锁超时配置

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

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

隔离级别

脏读

不可重复读

幻读

锁机制

读未提交(Read Uncommitted)

可能

可能

可能

不加锁

读已提交(Read Committed)

不可能

可能

可能

语句级快照

可重复读(Repeatable Read)

不可能

不可能

可能(*)

临键锁（默认）

串行化(Serializable)

不可能

不可能

不可能

全表锁

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

八、b2b供应网锁机制最佳实践

1. 锁优化口诀

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

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.”

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