前言

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

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

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

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

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

1.1 为什么需要锁？

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

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

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

二、锁的分类全景图

2.1 按粒度划分

按粒度划分为：

• 表锁
• 页锁
• 行锁

2.2 按模式划分

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

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）

显式加锁：

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

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

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

4.2 元数据锁（MDL）

保护表结构：

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

-- 会话B（被阻塞）
ALTER TABLE users ADD COLUMN 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 死锁检测与解决

自动检测：

SHOW ENGINE INNODB STATUS; 
-- 查看LATEST DETECTED DEADLOCK

手动处理：

// Spring事务重试
@Retryable(maxAttempts = 3, backoff = @Backoff(delay = 100))
@Transactional
public void transferMoney(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：

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

优化方案：

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

6.3 锁超时配置

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

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

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

八、锁机制最佳实践

8.1 锁优化口诀

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

8.2 不同场景锁选择

总结

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

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

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