MySQL中的 8 种锁!（mysql有几种锁,怎么写）
前言
在双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）
显式加锁：
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秒七、不同隔离级别的锁差异
隔离级别 | 脏读 | 不可重复读 | 幻读 | 锁机制 |
读未提交(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.”
最高明的锁策略是“无锁”，而这正是我们不断优化的方向。