前言
在双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解决幻读问题。
八、锁机制最佳实践
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.”
最高明的锁策略是“无锁”，而这正是我们不断优化的方向。
