MySQL（关系型数据库）事务边界与隔离级别

热身 · 一 事务边界 · 二 四项属性 · 三 失败处理 · 四 并发读 · 五 隔离级别 · 六 读写边界 · 七 应用 · 检验 · 表达 · 追问 · 隔日复测

学完能做到什么，为什么现在学

面对“修改办件状态＋保存审批记录”，你能划定一次本地 transaction（事务）的范围，说明成功与失败各怎么结束；给出两个数据库连接的读写顺序时，能判断 READ COMMITTED（读已提交）与 REPEATABLE READ（可重复读）下普通查询的结果，并说清判断前提。

和前几课的联系： 第10课讲了怎样为一条查询提出索引候选。接下来从“怎样查得合适”转向“多步操作和并发查询是否正确”。本课仍用办件例子，不依赖 JVM（Java 虚拟机）的内容。一次真实作答中容易混淆的地方，整理在本课末尾的课后问答。

前置： 知道一行是一条记录，能读懂按编号查询、修改状态和新增记录。 范围： 同一数据库连接、两张 InnoDB（事务存储引擎）表。必学为编号正文、一次应用与表达；拓展可稍后读。第三节后可暂停。MVCC（多版本并发控制）的版本判定细节、锁范围和框架事务留到后续深入。

主读： 官方 Consistent Nonlocking Reads（一致性非锁定读）。只读前五段，核对“自己的写入”“首次读建立快照”“每次读建立快照”；先完成第五节时间线再读原文更容易。速查表可随时查。

热身：先回忆前几课（3分钟）

先凭记忆回答，再展开核对。如果刚学完第10课，可以隔一天再答这两道变式；刚看完就答，检验不出隔日记忆。答不上来也不影响学习新课。

一、事务边界：先找出哪些操作必须成组

“办件已显示审批通过，但审批记录没保存，怎么避免？”

教学场景：1101号办件原来是“待审批”，没有审批通过记录。点击通过后要做两件事：在办件表把状态改成“已通过”；在审批记录表新增一条“1101号已通过”。本例业务规则是： 提交成功后，状态与对应记录必须匹配 。如果第二步失败，不能只留下第一步的结果。

transaction（事务）把一组数据库操作放在同一个处理单元。用 START TRANSACTION（开始事务语句）开始，全部完成后用 COMMIT（提交语句）确认；需要放弃时用 ROLLBACK（回滚语句）撤销本次未提交修改。它们属于 当前数据库连接 ：第一步用连接甲、第二步用连接乙，不能靠甲的一次提交把两边自动包起来。[1][2]

autocommit（自动提交）默认开启。没有显式开始事务时，普通的单条数据修改通常各自构成一个事务，成功后分别提交。这样“修改状态”可能已经提交，后面的“新增记录”失败也撤不回前一条。 不是没有事务，而是两条语句没在同一个事务里。 [1]

事务边界应围绕这组必须一起完成的数据库修改，不能把“等待用户点确认”也包进去。事务期间可能持有锁；长时间不结束还可能让旧版本保留更久。具体锁在第六节解释。[3][8]

二、ACID（事务四项属性）：把名字对应到这次审批

“事务的四项属性是什么？原子性和一致性有什么区别？”

先用具体动作理解，再记名字。下面“一致性”的业务规则是我们的教学设定；数据库不会自动理解“审批必须写记录”，仍要靠正确的程序、数据约束和事务使用。[4]

可以这样区分前两项：atomicity（原子性）问“这组修改是否一起生效”；consistency（一致性）问“生效后是不是合法的业务状态”。如果代码把状态和记录都写成错误内容，再完整提交，仍可能违反业务规则。本课先理解职责，恢复日志和刷盘参数另讲。[4]

三、失败处理：报错后必须知道撤销到了哪一层

“第二条语句插入重复键报错，第一条状态更新会自动撤销吗？”

不能这样假定。InnoDB（事务存储引擎）有的错误只回滚失败语句，有的会回滚整个事务。普通 INSERT（插入语句）产生 duplicate-key error（重复键错误）且未使用忽略错误选项时，只回滚该语句；之前成功的状态更新仍可能留在当前事务中。此时再提交，仍会留下不完整业务结果。[3]

实现风险： 下面是客户端控制流程的伪代码，不是可以整段粘贴执行的 SQL（结构化查询语言）。假设表支持事务、使用同一连接，固定办件号仅作演示；实际输入先核对权限与状态，再用绑定参数传值。错误必须保留并向调用方报告，不能捕获后继续走成功分支。

开始事务
尝试：
    更新1101号办件状态，并检查是否确实更新了预期记录
    如果业务条件不成立：进入失败分支
    插入1101号审批记录
    两步都成功：提交事务
失败分支：
    请求回滚本次事务
    如果回滚也失败：保留原始错误和回滚错误，交由连接管理处理
    向调用方报告失败，不继续提交

验证思路：模拟三种结果：两步成功→状态与记录都保存；第二步普通重复键错误→显式回滚后两步都不保留；未找到可审批记录→不插入通过记录并结束事务。本例检查失败分支，不把伪代码当成运行过的数据库程序。

业务判断失败也可能没有数据库异常，例如办件早已处理完成。这时应用要检查执行结果，不能仅凭“没有抛异常”就继续写通过记录。

可在这里暂停。先能说明“两步一起提交＋失败明确回滚”，再看下一部分的并发读取。

四、并发读取：先看发生什么，再给现象取名字

“脏读、不可重复读、幻读有什么区别？”

数据库连接A负责查看办件，连接B负责审批。每个连接可以有自己的事务，两个事务会交错执行。下表是三种 现象定义 ，不是说所有隔离级别都会发生。先关注B有没有提交，以及A看到的是同一行的变化，还是符合条件的记录集合变化。[12]

不要只背“幻读是条数变化”：即使条数恰好相同，结果集合的成员也可能变化。这里选新增一行，是为了把现象讲清楚。[11]

五、隔离级别：两次查询用哪个时间点看数据

“读已提交和可重复读有什么区别？快照什么时候建立？”

先定义 consistent read（一致性读）：数据库按规则选择这次查询能看到的已提交版本，也能看到本事务此前的修改。为了容易推演，下文称这个可见版本范围为 snapshot（快照）。它不是每次复制一整张表，而是按可见性规则利用旧版本还原结果。[6][8]

InnoDB（事务存储引擎）默认级别为 REPEATABLE READ（可重复读），但实际连接配置可能被修改，应以连接设置为准。四个级别先掌握下表；本课主要练中间两个。[5]

时间线：第二次读为什么不同

共同前提： 1101初始状态为0（待审批）。A保持同一个显式事务，只执行普通 SELECT（查询语句），不加锁、不修改数据。B改成1（已通过）并提交；没有其他写入。以下是基于官方规则的教学推演。

在 READ COMMITTED（读已提交）下，③建立新快照，能读到B已提交的1。在 REPEATABLE READ（可重复读）下，③仍按①建立的快照读取，得到0。A结束事务后再开新事务读取，才能在这个例子里得到更新的1。[6]

首次读，和开始事务，不是同一个动作。 普通 START TRANSACTION（开始事务语句）之后，如果A还没做第一次一致性读，B就提交了1，那么A第一次读会看到1；不能把事务开始时间直接当成快照时间。[6]

六、读写边界：看见待审批，不等于拿到了审批权

“普通查询读到了待审批，下一步直接更新，就不会重复审批了吗？”

不保证。普通一致性读给你可见的版本，其他连接仍可修改对应记录。两个经办人可能先后都读到待审批；稳定地看到旧值，不等于阻止了别人处理。

MVCC（多版本并发控制）保留还原旧行版本所需的信息，让一致性读可以按快照看到合适版本。与之不同，locking read（锁定读）要读取并锁住相应记录，为后续检查和修改提供保护。以按主键找1101为例，SELECT … FOR UPDATE（查询并加更新锁）会读取最新可用数据并加锁；遇到冲突的未结束事务，可能等待。[7][8]

START TRANSACTION;
SELECT status FROM case_item WHERE id = 1101 FOR UPDATE;
-- 取得结果后，仍要确认存在且状态为待审批
-- 再按第三节流程更新状态、插入审批记录、提交；失败则回滚

验证思路：在两个测试连接中按主键查询同一条记录。A在事务内取得更新锁后不结束，B的冲突更新应等待；A结束后B才能继续。实际执行时必须依第三节补全结束分支，不能复制这段后让事务一直挂着；本段是读取步骤示意，不是完整审批程序。

这就是常说的 snapshot read（快照读）与 current read（当前读）的差别：前者按可见版本读；后者用于本文的锁定读取和写操作，不能套用旧快照的普通查询结论。 UPDATE（更新语句）也不能简单理解为只更新第一次查询曾看到的那些旧行。 即使需要等待，取得保护后仍要重新核对状态，不能复用更早一次普通查询的判断。[6][7]

本课不要求背出每种查询锁住哪个范围。先记住：按主键锁定读取只解决本事务的数据库并发保护；锁在提交或回滚后释放。短信已经发出、另一个服务已经执行的动作，不会被本数据库的回滚自动撤销，因此它们不能被当成普通的同库修改。[7][2]

七、完整应用：先判断失败，再推演读数

“你会怎样处理审批失败，又怎样复现两种读取结果？”

先做这两个纸上判断，再展开答案；不用从头编写数据库程序。

1. 同一事务中，状态更新成功，新增记录发生普通重复键错误。代码捕获后打印日志，继续提交。最终可能留下什么？应把流程改在哪里？
2. A在可重复读的事务里先读到状态0；B改成1并提交；A再普通查询。结果是什么？若只把A改为读已提交，结果又是什么？前提是A不写、不加锁。

-- 准备阶段：连接B，确认处于自动提交模式且没有活动事务
CREATE TABLE teach_tx_0011 (
  id BIGINT PRIMARY KEY,
  status TINYINT NOT NULL
) ENGINE=InnoDB;
INSERT INTO teach_tx_0011 VALUES (1101, 0), (1102, 0);

-- 步骤1：连接A；先执行到第一次查询，停下
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT status FROM teach_tx_0011 WHERE id = 1101;
-- 预期0

-- 步骤2：切到连接B，单条修改在自动提交模式下成功提交
UPDATE teach_tx_0011 SET status = 1 WHERE id = 1101;

-- 步骤3：回连接A
SELECT status FROM teach_tx_0011 WHERE id = 1101;
-- 同一事务预期仍为0
COMMIT;
SELECT status FROM teach_tx_0011 WHERE id = 1101;
-- 新的查询事务预期为1

推广到其他业务： 办件状态＋流转记录、材料状态＋审核记录，都可能有成组修改需求。可以另找一组必须一起提交的数据，说明事务边界怎么划；如果只是拟定方案，就明确说“如果这样设计”。本课伪代码是教学示意，不是线上实现。

八、即时检验：合上正文，做一次即可

6 道题，每题选项长度一致。先回答，再展开核对；不会的题记下来回到对应小节，不要求反复刷到全对。

1. 默认开启自动提交，未显式开始事务。先更新状态成功，再插入记录失败，会怎样？

• A. 两条修改必定全撤销
• B. 前条修改可能已提交
• C. 两条语句自动成一组

2. 显式事务中第二条普通插入报重复键错误，未使用忽略错误选项。应用应怎样处理这次业务失败？

• A. 停止成功流程并回滚
• B. 捕获之后继续去提交
• C. 认定全部自动被撤销

3. A在同一可重复读事务里先普通查询到0；B改成1并提交。A不写、不加锁，第二次普通查询读到什么？

• A. 这次读到一
• B. 必定读失败
• C. 仍然读到零

4. 第3题只把A改成读已提交，第二次普通查询读到什么？

• A. 仍然读到零
• B. 这次读到一
• C. 必定读失败

5. A在可重复读下只执行普通开始事务，尚未读取。B改成1并提交，A这时第一次普通查询，如何判断？

• A. 开始时锁定旧值
• B. 开始时复制全表
• C. 首次读取看到一

6. 普通查询读到待审批，就能保证其他连接无法审批同一办件吗？

• A. 不能保证写入独占
• B. 自动锁住整张表格
• C. 自动阻止其他审批

九、用完整回答检验理解

连续回答四问，先不看参考答案。可以写下来，也可以先口述再整理成文字；每问只处理一组相关问题，第二问不再把不同主题挤进一句。写完再对照各节的参考回答。

1. 审批状态和审批记录怎样一起保存？默认自动提交为什么不够？
2. 第二条插入普通重复键报错时，你的失败分支怎么结束这次事务？
3. A先读、B修改并提交、A再读。读已提交和可重复读各看到什么？请明确“同一事务、普通查询、自己不写”这三个前提。
4. 举一个需要两步成组修改的业务场景。为什么普通查询到待审批还不够，怎样保护后续审批？

练习：请在自己的笔记中写出答案，再展开参考内容核对。

十、集中追问：先说，再展开

答案都在前文

十一、隔日复测：换条件再提取（约5分钟）

隔一天、开始新内容前回答；约一周后再换数字复述。不要在刚看完答案时立刻连续重做。

主来源与引用

本课末尾的课后问答：自动提交、回滚与并发审批。

事务速查表。本课办件、状态编码和动作顺序为教学设定，不是线上项目证据。

1. 自动提交、提交和回滚：默认模式与成组修改。

2. 事务控制语句：提交、回滚、连接范围和显式快照。

3. 错误处理：单语句与整个事务的回滚范围。

4. 事务四项属性：可靠性职责与配置条件；审批业务规则是课堂应用。

5. 事务隔离级别：默认值、四个级别及具体读写差异。

6. 一致性非锁定读：快照建立时机、自己的写入例外。

7. 锁定读：查询后修改的保护、等待与释放。

8. 多版本存储：保留旧版本信息、还原旧行与长事务代价。

9. 隐式提交：改表与开始新事务的边界。

10. 设置事务特征：只改下一事务的实验设置。

11. 幻影行：现象与范围保护。

12. 官方术语表：三种读现象定义，具体级别行为以前述实现章节为准。

学完后，可以沿第五节的时间线，用自己的话解释“B提交以后，A为什么还是0”；卡住时回到时间线逐步核对两个连接的动作。下一课继续 MVCC（多版本并发控制），之后是锁的专题。

课后问答：理解是怎样变化的

问题与结论默认可见。展开后可看理解过程；以下根据真实交流整理，并非逐字稿。

更新办件状态和插入审批记录，默认 autocommit（自动提交）下为什么不能保证两步一起保存？第二条插入报普通重复键错误时，事务又该怎样结束？

最终结论： 默认自动提交不够，是因为两步没有放在同一个事务里，会各自提交。正确做法是在同一连接中显式开始事务，两步都成功才 COMMIT（提交）；第二步报错时，停止成功流程，请求 ROLLBACK（回滚）整个事务并报告错误，不能捕获后继续提交。

A在同一事务里先普通查询，B修改该行并提交，A再普通查询。READ COMMITTED（读已提交）和 REPEATABLE READ（可重复读）下，A第二次各读到什么？为什么？

最终结论： 读已提交每次一致性读都建立新快照，所以第二次读到B已提交的新值；可重复读在同一事务中复用首次一致性读建立的快照，所以仍看到第一次的旧值。

两个经办人可能同时审批同一件办件。普通查询读到“待审批”后直接更新，能防止重复审批吗？应该怎样保护？

最终结论： 在同一事务内按办件主键执行 SELECT … FOR UPDATE（查询并加更新锁），取得记录后核对是否仍为待审批；满足条件才更新状态、写入审批记录并提交，失败则回滚。另一方如果在等锁，取得锁后必须重新检查本次读到的状态，不能沿用等待之前的判断；若已审批完成，按业务规则返回“已处理”，不重复写通过记录。

规则是一件只能审批通过一次、只生成一条通过记录。A、B各自在事务内按主键锁定查询→核对状态→更新→新增记录→提交。A先完成并提交，B取得锁后读到“已通过”。B还要修改吗？B的事务怎样结束？

最终结论： B读到“已通过”后不再修改，向调用方返回“该办件已处理”，并显式以 COMMIT 或 ROLLBACK 结束自己的事务、释放锁；不能只从代码分支返回而让事务一直挂着。