在双11期间,支付宝数据库集群每秒处理25万笔交易,而支撑这一切的核心技术之一就是MySQL的锁机制。
很多小伙伴在工作中都遇到过这样的场景:
这篇文章跟大家一起聊聊MySQL的8种锁,希望对你会有所帮助。
当多个事务同时操作同一数据时,可能引发:
锁的作用:通过对数据资源加锁,实现事务的隔离性(ACID中的"I")
按粒度划分为:
锁类型 | 共享性 | 典型场景 |
---|---|---|
共享锁(S) | 可共享 | SELECT ... LOCK IN SHARE MODE |
排他锁(X) | 独占 | UPDATE/DELETE/INSERT |
意向共享锁(IS) | 表级标记 | 准备加行级S锁前 |
意向排他锁(IX) | 表级标记 | 准备加行级X锁前 |
锁定索引记录:
-- 事务A
BEGIN;
SELECT * FROM users WHERE id = FOR UPDATE; -- 对id=1加X锁
-- 事务B(将被阻塞)
UPDATE users SET name = 'Tom' WHERE id = ;
底层实现:
锁定索引区间(解决幻读):
假设当前表结构:id主键(当前有id=1,5,10)
BEGIN;
SELECT * FROM users WHERE id BETWEEN AND FOR UPDATE;
-- 阻塞所有[5,10]区间的插入
INSERT INTO users(id) VALUES(); -- 被阻塞!
INSERT INTO users(id) VALUES(); -- 成功
锁定范围:
记录锁+间隙锁组合:
假设当前数据库隔离级别是RR(Repeatable Read):
BEGIN;
SELECT * FROM users WHERE id > FOR UPDATE;
-- 阻塞操作
UPDATE users SET name='A' WHERE id=; -- 记录锁阻塞
INSERT INTO users(id) VALUES(); -- 间隙锁阻塞
锁范围示意图:
显式加锁:
LOCK TABLES users WRITE; -- 获取写锁
-- 执行更新...
UNLOCK TABLES;
隐式加锁(DDL操作自动加锁):
ALTER TABLE users ADD COLUMN age INT; -- 自动加表级X锁
保护表结构:
-- 会话A
BEGIN;
SELECT * FROM users; -- 获取MDL读锁
-- 会话B(被阻塞)
ALTER TABLE users ADD COLUMN email VARCHAR();
等待链:
-- 事务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 = ;
死锁形成过程:
自动检测:
SHOW ENGINE INNODB STATUS;
-- 查看LATEST DETECTED DEADLOCK
手动处理:
// Spring事务重试
@Retryable(maxAttempts = , backoff = @Backoff(delay = ))
@Transactional
public void transferMoney(Long from, Long to, BigDecimal amount) {
// 转账逻辑
}
-- 查看锁等待
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
问题SQL:
UPDATE users SET status= WHERE name LIKE 'A%'; -- 无索引导致表锁
优化方案:
ALTER TABLE users ADD INDEX idx_name(name); -- 创建索引
UPDATE users SET status= WHERE name LIKE 'A%'; -- 仅加行锁
# my.cnf
[mysqld]
innodb_lock_wait_timeout=50 # 默认50秒
隔离级别 | 脏读 | 不可重复读 | 幻读 | 锁机制 |
---|---|---|---|---|
读未提交(Read Uncommitted) | 可能 | 可能 | 可能 | 不加锁 |
读已提交(Read Committed) | 不可能 | 可能 | 可能 | 语句级快照 |
可重复读(Repeatable Read) | 不可能 | 不可能 | 可能(*) | 临键锁(默认) |
串行化(Serializable) | 不可能 | 不可能 | 不可能 | 全表锁 |
InnoDB在RR级别通过Next-Key Lock解决幻读问题。
场景 | 推荐方案 |
---|---|
精确更新单行 | 行级X锁(WHERE主键) |
范围更新 | Next-Key Lock(RR隔离级别) |
全表更新 | 分批提交+低峰期执行 |
结构变更 | PT-Online-Schema-Change工具 |
SHOW ENGINE INNODB STATUS
正如数据库专家Michael Stonebraker所言: “The best locking strategy is no locking at all.”
最高明的锁策略是“无锁”,而这正是我们不断优化的方向。