第5章 并发病房：事务与锁

第 5 章 · 并发病房：事务与锁

本章要回答的三个问题：事务的 ACID 各靠什么机制兑现？四个隔离级别分别治什么病、留下什么副作用？线上卡死的更新语句，怎么区分是锁等待还是死锁，怎么急救？

为什么会有这一章

单条查询的病在第 4 章治完了，但生产库从来不是一个人在看病。两个事务同时改同一行、一个长查询挡住一排更新、互相握着对方要的锁——并发病房里的病例往往表现为"整站卡住"而不是"某条 SQL 慢"。不懂锁与隔离，这类病例连病史都问不出来。

读完能解决什么

• 能把 ACID 四个词对应到 redo、undo、锁、MVCC 的具体机制
• 能按业务容忍度选隔离级别，说清脏读、不可重复读、幻读的差别
• 会用数据字典定位锁等待，会读死锁日志并化解循环等待

各节怎么分工

先决条件

第 3 章 undo/redo 的分工、第 2 章的事务语句。

往下走到哪

病房稳定后进第 6 章康复训练：分区表、参数调优，让这台机器跑得更快。

并发问题的分诊入口

病房接诊要学会先分诊再进病房。拿到"卡住"的主诉，第一问是"谁卡住"：单条 SQL 慢，多半是 4 章的扫描问题，先拍执行计划；一批更新互相排队，进 5.3 查锁；读到的数据时有时无像闹鬼，进 5.2 查隔离级别与快照口径；系统整体越来越慢且重启即愈，怀疑长事务拖累 purge，查 INNODB_TRX 与 History list length。四种症状四个入口，分诊对了，处理流程本章各节都写好了。

并发是数据库从"能用"到"敢上生产"的分水岭。单机练习时建议亲手做三件事再离开本章：复现一次死锁并读懂死锁日志；复现一次锁等待并用 data_locks 取证；开一个不提交的事务观察 History list length 的增长。三件事各十分钟，换来的是线上第一次并发事故时不慌。
关于本章的 meta 建议也值得记录：事务与锁的知识特别适合"实验驱动"学习，本章所有案例都设计成两个终端就能复现的形态，正是为了这个。学并发最好的方式从来不是读，是亲手制造一次死锁、亲眼看着它被检测回滚、亲手从日志里把它解剖。每做完一个实验，把当时的会话操作与输出存成自己的实验记录——本章五六个实验的记录，就是一份个人版的并发病房操作手册，比任何转述的教程都更贴近真实手感。
并发话题的最后一层是团队协作：锁与事务的问题多数是跨模块的，A 模块的事务顺序与 B 模块不同，死锁才会出现，所以加锁顺序、事务时长红线、外部调用禁令这些规矩必须写进团队共同的编码规范，而不是散落在各模块作者的私人习惯里。建议把本章的三张表——隔离级别副作用表、锁家族速查表、预防处方排序表——直接搬进团队 wiki，配上本团队的真实例。规范有了公共版本，第 5 章的知识才从个人技能变成团队资产。
并发能力的进阶路线也顺带一提：本章过后，值得一读的下一站是应用层的一致性设计——分布式事务的各种方案、幂等与重试的边界、消息队列与本地事务的配合，它们与数据库事务共同构成完整的一致性工具箱。带着本章的 ACID 与隔离直觉去读那些方案，会清楚看到哪些是在数据库之外重新发明事务、哪些是在放松约束换吞吐。地基扎实的读者，看任何上层方案都能一眼看到它站在哪块地基上。