MySQL 事务与锁机制实战：从隔离级别到死锁排查

促销活动上线第一天客服群里炸了——使用者反馈“明明提示下单成功，库存却变成负数”。排查代码发现，扣库存的逻辑是：

// 伪代码：一个经典的"看似没问题"的扣库存
@Transactional
public void deductStock {
int stock = mapper.selectStock;// 查库存 →
if {
mapper.updateStock;// 扣库存 →
}
}

@Transactional也加了WHERE 条件也用到了索引。问题出在哪，

问题出在一个关键认知上：事务 ≠ 锁。InnoDB 默认的 REPEATABLE READ 隔离级别下SELECT 是快照读——它读到的是事务开始时的数据版本，不会加锁。两个事务同时读到 stock=100，都判定 ">0"。都执行 UPDATE stock=99库存就变成了 -1。

sequenceDiagram
participant T1 as 事务1
participant DB as MySQL
participant T2 as 事务2
说到T1->DB，SELECT stock →
再看T2->DB，SELECT stock →
T1->DB这方面，UPDATE stock = 99
T2->DB这方面。UPDATE stock = 99
至于T1->DB，COMMIT
说到T2->DB，UPDATE stock = 98
Note over T1,T2: 库存本应是98，实际是99 👎

要彻底理解为什么会出这个问题、还有怎么正确解决，你需要掌握三个主要概念：隔离级别Mvcc锁机制。这篇文章就从实际运行出发，逐一验证。其实，

测试环境

# 启动 MySQL
docker run -d --name mysql_txn \
-e MYSQL_ROOT_PASSWORD=123456 \
-p 3306:3306 \
mysql:8
# 打开两个终端窗口。分别作为 Session A 和 Session B
docker exec -it mysql_txn mysql -uroot -p123456
# 初始化测试数据
DROP DATABASE IF EXISTS txn_test;说起来，CREATE DATABASE txn_test CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;USE txn_test;CREATE TABLE account (
id BIGINT PRIMARY KEY AUTO_INCREMENT,name VARCHAR NOT NULL。balance DECIMAL NOT NULL DEFAULT 0,INDEX idx_name
) ENGINE=InnoDB;CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,order_no VARCHAR NOT NULL,user_id BIGINT NOT NULL,amount DECIMAL NOT NULL。status TINYINT NOT NULL DEFAULT 0,create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,INDEX idx_user_id,INDEX idx_status,INDEX idx_user_status
) ENGINE=InnoDB;INSERT INTO account VALUES，;INSERT INTO orders VALUES，;

一、四种隔离级别实战验证

隔离级别速览表格

脏读复现

Pain Point:* 使用者看到的数据可能根本不存在因为它们来自未提交的修改；这直接导致业务错误和使用者投诉。

Description:* 在极低等级下一个未提交事务可以被另一个读取到，从而产生脏数据。

从*操作方式*来看。打开两个终端，分别执行 Session A 和 Session B 的 SQL。注意执行顺序和时机，

` Session B先执行： `SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;START TRANSACTION;说起来，UPDATE account SET balance = balance + 100 WHERE id = 1;-- ⚠️ 不要 COMMIT！此时去执行 Session A` `Session A 在 Session B 未提交期间执行： SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;START TRANSACTION;SELECT id,name。balance FROM account WHERE id = 1;老实说，-- 得到脏数据` `ROLLBACK;` `SELECT ...` ** **Result**: Session A reading balance... | id | name | balance | |----|-------|--------| | | Alice |?，?不过，| **Conclusion**: 🎯 Pain point:* 脏数据让业务失效。---

不可重复读复现

至于*痛点*。同一请求内两次查询得到不同结果，让业务逻辑难以保证一致性。*场景*的观点是，支付程序检查余额后立刻扣款。却被并发交易改变余额导致超额扣除。

sql -- Session A 开始长事务两次查询： SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;START TRANSACTION;SELECT balance FROM account WHERE id=1;-- 第一次 -- Session B 提交修改： START TRANSACTION;UPDATE account SET balance = balance +50 WHERE id=1;COMMIT，-- Session A 至于查询，SELECT balance FROM account WHERE id=1;-- 第二次不同值 COMMIT;Result: text Session A first read : bal =200 Session A second read : bal =250 ---

可重复读验证

至于*痛点*。并发写入不会影响已开启事务中的快照，可防止意外漂移，但仍需。

sql -- Session A 创建ReadView： SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;START TRANSACTION;SELECT * FROM orders WHERE order_no='ORD001';-- snapshot taken -- Session B 修改并提交： START TRANSACTION;UPDATE orders SET status=5 WHERE order_no='ORD001';COMMIT，-- Session A 查询的观点是，SELECT * FROM orders WHERE order_no='ORD001';-- still sees old snapshot COMMIT;Result: text First read shows status=0 Second read still shows status=0 – snapshot intact. ---

RR 下幻读漏洞：快照 vs 当前读取

sql -- Snapshot read: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;START TRANSACTION;SELECT * FROM orders ORDER BY id;-- Insert new row by anor session: START TRANSACTION;INSERT INTO orders VALUES; COMMIT，其实，-- Snapshot again inside same transaction: SELECT * FROM orders ORDER BY id;-- still old snapshot -- Current read using FOR UPDATE: SELECT * FROM orders WHERE status=5 FOR UPDATE;-- sees new row ->幻灯片！不过，---

SERIALIZABLE：连普通 SELECT 都加共享锁

sql SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;START TRANSACTION;SELECT * FROM orders WHERE order_no='ORD001';-- 自动加 S 锁 LOCKS IN performance_schema.data_locks show shared lock: LOCK_TYPE | LOCK_MODE | LOCK_DATA Record Lock | S,REC_NOT_GAP | BLOCKED example: SESSION-A holds S lock on row -> SESSION-B UPDATE blocked until commit. ---

二、MVCC：为什么 RR 能够做到可重复读取？

隐藏列 & 行版本链结构图解
隐藏列名	含义	作用域	$DB_TRX_ID$ : 最近一次更新该行所用事务 ID	$DB_ROLL_PTR$ : 指向 Undo Log 上上一版本；$DB_ROW_ID$ : 行标识	每一次 UPDATE 都会创建一个新的版本记录，并把旧版本写入 Undo Log；说起来，而 ReadView 则通过该链条判断行是否对当前事务可见。 Pain Point:* 若没有正确使用 MVCC 或者误用快照读取。就会出现超卖或脏数据，这正是我们在促销活动中看到的 “负库存” 问题。 MVC 原因：A transaction reads a snapshot at start time and uses a ReadView to determine visibility of each row version. MVC 优势：No blocking reads -> high concurrency for reads.

---

ReadView 如何决定能看到哪个版本？—— MVCC主要判断逻辑演示

sql boolean isVisible{ if return true;怎么说呢，// 自己改过 => 可见 if return true;// 前面已提交 => 可见 if return false;// 后面才开始 => 不可见 if) return false;// 活跃 => 不可见 return true;// 已提交且非活跃 => 可见 }

如果不可见，则顺着 $DBROLLPTR$ 回溯 Undo Log 找最近可见版本。

---

RC vs RR 的区别——ReadView 创建时机差异

隔离级别与 ReadView 创建时间对比表格
Level	首次 SELECT 时刻	后续 SELECT 时刻	是否能看到新改动	适合场景	READ COMMITTED	每个 SELECT 新建 View	新建 View	能看到新改动 ➜ 较高并发但易出现不可重复。适合互联网订单等高并发业务	REPEATABLE READ	第一次 Select 新建 View，接下来复用	同一 View ➜ 保持初始快照，不受后续更改影响；适合财务/账务等需要一致性快照场景

---

三、行锁实战观测与

三种典型行锁速览

---

实战观测三种典型行锁：

Record Lock 示例

sql START TRANSACTION;SELECT * FROM orders WHERE id =123 FOR UPDATE;SELECT ENGINE_TRANSACTION_ID,OBJECT_NAME,INDEX_NAME,LOCK_TYPE,LOCK_MODE,LOCK_STATUS。LOCK_DATA FROM performance_schema.data_locks WHERE OBJECT_SCHEMA ='txn_test' AND OBJECT_NAME ='orders';Result: text TABLE IX null # 表意向排他锁 RECORD X,REC_NOT_GAP # record exclusive lock – only this row locked *Pain point:* 未预料到 Record Lock 会使同一行在多线程中出现阻塞。

Gap Lock 示例

sql START TRANSACTION;SELECT * FROM orders WHERE id =500 FOR UPDATE;LOCK_TYPE : RECORD LOCK_MODE : X。GAP # exclusive gap lock on interval (,500] SESSION-B START TRANSAC…INSERT ，VALUES;--> ERROR : Lock wait timeout exceeded. *Pain point:* Gap Lock 可以避免幻影。但也可能导致插入堵塞，从而让高并发服务变慢。

Next‑Key Lock 示例

sql START TRANSAC…，SELECT * FROM orders WHERE user_id BETWEEN10 AND20 FOR UPDATE;*Pain point:* 范围查询会触发大量 Next‑Key Locks，从而明显提高死锁概率。

---

锁规则口诀

• "等值命中 ⇒ Record Lock"
• "等值不命中 ⇒ Gap Lock"
• "范围查询 ⇒ Next‑Key + Range Gap"
• "唯一索引优先 – 小范围。高吞吐"
• "非唯一索引 → 大范围，加大争抢"
• "常规业务建议使用唯一索引 + RC 或 RR+FOR UPDATE"
• "若业务不需要完整快照，可降至 RC 更友好"
• "如果你想避免 '当前读取' 导致幻影，请记住 FOR UPDATE 必须使用！"

---

四、死锁复现与排查实践

死锁案例—交叉更新

两笔转账按不同顺序更新同两条记录，引起相互等待。sql /* Prepare initial balances */ UPDATE account SET balance=10000 where ID in;/* Transaction A */ START TRANSAC…，UPDATE account SET balance =balance+200 where ID=10101;SLEEP，/* 给 Transaction B 时间先占另一条 */ UPDATE account SET balance =balance-200 where ID=10102;COMMIT，/* Transaction B */ START TRANSAC…，UPDATE account SET balance +=200 where ID=10102;SLEEP，UPDATE account SET balance -=200 where ID=10101;COMMIT，Result: text Transaction B -> Deadlock found when trying to get lock…Transaction A aborted due to deadlock victim selection.

死锁日志解析工具

Lock Types & Their Scope
X。REC_NOT_GAP – 单行 exclusive lock — No gap lock — 快速且无幻影风险 — ✅ 优秀性能 “只锁目标记录”，无需阻塞其他插入或更新。

命令	用途
SHOW ENGINE INNODB STATUS\G	查看最近一次死锁详情
SELECT * FROM performance_schema.data_locks	当前所有持有和等待中的所有行/gap 锁
SELECT * FROM performance_schema.data_lock_waits	当前等待关系
SHOW ENGINE INNODB STATUS\G	查看详细死lock 图形

死lock 日志阅读技巧

① 看 HOLDS THE LOCK – 每个事务持有什么；老实说，② 看 WAITING FOR THIS LOCK TO BE GRANTED – 每个等待什么；③ 用这些信息画出 等待图 – 确认环路即为死lock。

避免死lock 的常用方法

• # 固定资源访问顺序——最有效手段。怎么说呢，
• # 缩短事务持续时间 —— 持久化时间越短冲突越少。
• # 使用唯一索引 —— 等值命中退回 Record Lock，减少间隙争抢。
• # 若业务允许，可考虑 **READ COMMITTED** 而非 RR。以减少间隙与 next-key lock 的使用。
• # 在应用层捕获 `DeadlockLoserDataAccessException` 并重试。

  五、如何快速选取合适隔离级别？

  'Isolation Level'	'Concurrency Issue'	'Suitable Scenario'
  'READ UNCOMMITTED'	'Dirty read / non-repeatable / phantom reads almost none.'- Only for reports tolerant of dirty data.	'Report generation or analytics with stale tolerance.'
  'READ COMMITTED''Non-repeatable read + phantom reads.'
  'REPEATABLE READ''Phantom reads via current-read.'
  'SERIALIZABLE' 🎯 **选型建议**：如果业务不需要完整“可重复快照”。推荐 **RC + 行加鎖** 或 **RR + FOR UPDATE** 而不是纯 RR，以降低间隙鎖带来的潜在死lock 与性能瓶颈。通过上述实验，我们清晰看到了： 快照读取和当前读取之间的差异直接决定是否出现“负库存”的 bug； MVCC 与 ReadView 控制着行版本可视性； InnoDB 的三种行鎖类型还有它们在不同查询语句中的应用；话说回来， 如何利用日志诊断复杂 deadlock 场景； 最终给出针对具体业务需求的一套合理隔离级水平方案。 下面给你一份“一张图”方便你回顾主要概念及其关系，也提供快速检索表格供你日常排查之用。 主要概念一张图 快速检索表格