前言在双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）锁定索引记录：
代码语言：javascript复制-- 事务A
BEGIN;
SELECT * FROM users WHERE id = FOR UPDATE; -- 对id=1加X锁
-- 事务B（将被阻塞）
UPDATE users SET name = 'Tom' WHERE id = ;
底层实现：
图片3.2 间隙锁（Gap Lock）锁定索引区间（解决幻读）：
假设当前表结构：id主键（当前有id=1,5,10）
代码语言：javascript复制BEGIN;
SELECT * FROM users WHERE id BETWEEN AND FOR UPDATE;
-- 阻塞所有[5,10]区间的插入
INSERT INTO users(id) VALUES(); -- 被阻塞！
INSERT INTO users(id) VALUES(); -- 成功
锁定范围：
图片3.3 临键锁（Next-Key Lock）记录锁+间隙锁组合：
假设当前数据库隔离级别是RR（Repeatable Read）：
代码语言：javascript复制BEGIN;
SELECT * FROM users WHERE id > FOR UPDATE;
-- 阻塞操作
UPDATE users SET name='A' WHERE id=; -- 记录锁阻塞
INSERT INTO users(id) VALUES(); -- 间隙锁阻塞
锁范围示意图：
图片四、表级锁：全表扫描的保护伞4.1 表锁（Table Lock）显式加锁：
代码语言：javascript复制LOCK TABLES users WRITE; -- 获取写锁
-- 执行更新...
UNLOCK TABLES;
隐式加锁（DDL操作自动加锁）：
代码语言：javascript复制ALTER TABLE users ADD COLUMN age INT; -- 自动加表级X锁
4.2 元数据锁（MDL）保护表结构：
代码语言：javascript复制-- 会话A
BEGIN;
SELECT * FROM users; -- 获取MDL读锁
-- 会话B（被阻塞）
ALTER TABLE users ADD COLUMN email VARCHAR();
等待链：
图片五、死锁：高并发的终极挑战5.1 经典死锁场景代码语言：javascript复制-- 事务A
BEGIN;
UPDATE accounts SET balance = balance - WHEREid = ;
UPDATE accounts SET balance = balance + WHEREid = ;
-- 事务B（反向操作）
BEGIN;
UPDATE accounts SET balance = balance - WHEREid = ;
UPDATE accounts SET balance = balance + WHEREid = ;
死锁形成过程：
图片5.2 死锁检测与解决自动检测：
代码语言：javascript复制SHOW ENGINE INNODB STATUS;
-- 查看LATEST DETECTED DEADLOCK
手动处理：
代码语言：javascript复制// Spring事务重试
@Retryable(maxAttempts = , backoff = @Backoff(delay = ))
@Transactional
public void transferMoney(Long from, Long to, BigDecimal amount) {
// 转账逻辑
}
六、锁监控与优化实战6.1 锁等待分析代码语言：javascript复制-- 查看锁等待
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
6.2 索引优化避免全表锁问题SQL：
代码语言：javascript复制UPDATE users SET status= WHERE name LIKE 'A%'; -- 无索引导致表锁
优化方案：
代码语言：javascript复制ALTER TABLE users ADD INDEX idx_name(name); -- 创建索引
UPDATE users SET status= WHERE name LIKE 'A%'; -- 仅加行锁
6.3 锁超时配置代码语言：javascript复制# 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.”
最高明的锁策略是“无锁”，而这正是我们不断优化的方向。