事务、隔离级别与 MVCC

事务把一组状态变化变成一个提交单位。边界过小会暴露中间状态，边界过大则延长锁、undo 和连接占用。InnoDB 的 MVCC 让普通读取与写入有复杂但可解释的交互，必须区分一致性读和当前读。

一、学习目标

理解自动提交、显式事务与隐式提交
用 ACID 分析业务原子单位
区分一致性读、锁定读和快照
比较四种隔离级别的可见性
控制事务长度、错误与重试边界

二、事务边界与自动提交

默认 autocommit=1 时每条 DML 自成事务。创建订单需要多表一致：

START TRANSACTION;
INSERT INTO orders (...);
INSERT INTO order_items (...);
UPDATE products SET stock = stock - ? WHERE id = ? AND stock >= ?;
COMMIT;

任何步骤失败都应 ROLLBACK。连接断开通常触发回滚未提交事务，但应用仍需明确处理错误。许多 DDL 会隐式提交，不能混在期望可整体回滚的 DML 事务中。

三、ACID 与持久性

原子性保证事务内变化全有或全无；一致性依赖约束和正确业务逻辑；隔离控制并发可见性；持久性与 redo、刷盘配置和硬件有关。

“数据库支持 ACID”不代表任意跨服务操作自动原子。发送邮件、调用支付和写 MySQL 需要 outbox、幂等或补偿等模式。StudyStore 事务只覆盖同一 MySQL 实例内订单和库存。

四、MVCC 与一致性读

InnoDB 使用版本信息提供一致性非锁定读。在默认 REPEATABLE READ 下，事务中第一次一致性读建立快照，后续普通 SELECT 通常看到同一快照；自己事务的修改可见。

SELECT ... FOR UPDATE 是当前锁定读，读取最新可见版本并加锁，行为与普通 SELECT 不同。同一事务混用快照读和当前读时，结果看似矛盾却符合各自语义，必须按目的选择。

五、隔离级别

READ UNCOMMITTED：可能读到未提交变化，很少适合业务。
READ COMMITTED：每条一致性读建立新快照，减少部分间隙锁。
REPEATABLE READ：事务级快照，是 InnoDB 默认。
SERIALIZABLE：把普通读加强为更严格冲突，吞吐代价高。

隔离级别不是越高越好。选择要结合读写模式、显式锁、重试能力和一致性需求，并用两个连接演示实际可见性。

六、长事务与重试

长事务积累 undo、阻碍清理、延长锁和复制应用。不要在事务中等待用户输入、远程 HTTP 或大文件处理；先准备外部数据，再开启短事务。

死锁或临时冲突可能要求重试整个事务函数，而不是只重试最后一条语句。事务内操作必须幂等或从头重新读取状态。提交结果不确定时，使用业务请求键查询最终状态，不能直接重复扣库存。

七、从知识点到工程契约

本篇 SQL 最终要运行在长期存在的 schema、连接和事务中，而不是只在一个临时查询窗口里得到一次正确结果。先写清输入表与行数、会话设置、事务边界、允许的锁、期望结果和失败后的状态，再决定使用约束、查询、索引、存储对象还是运维命令。数据库行为同时受到版本、隔离级别、字符集、统计信息和并发会话影响，示例必须把这些前提显式化。

可以用以下顺序把知识点落到 StudyStore：

在全新数据库按迁移顺序建立最小 schema，保存 SHOW CREATE TABLE 与关键会话变量。
加入一个与“以为多条自动提交语句天然属于同一事务”相关的反例，记录错误码、SQLSTATE、事务是否仍可用以及数据是否改变。
为正常、空集、边界值、重复值和并发冲突准备确定性种子，不依赖手工残留数据。
对读查询检查结果集和 EXPLAIN ANALYZE；对写操作同时检查受影响行数、约束、提交与回滚。
最后才讨论性能优化。索引和参数调整必须有执行计划、等待事件或容量数据支持，并保留变更前基线。

审查数据库设计时至少回答四个问题：谁能写，哪条约束保护不变量，事务在哪一层结束，失败后如何恢复。MySQL 能保证声明范围内的事务和持久性，却不会替应用补上缺失约束、幂等键、备份演练或最小权限。只要这些问题没有明确答案，就不要把一次成功执行当成生产方案。

本篇最重要的能力是“理解自动提交、显式事务与隐式提交”。能由主键、唯一键、外键、CHECK 或数据类型表达的规则，应优先落到数据库；需要跨聚合或外部系统判断的规则，再由应用和事务协调。不要用注释或约定替代可执行约束。

八、验证策略与复盘

验证分为 schema、数据、并发和恢复四层。schema 层检查定义与会话基线；数据层断言结果和约束；并发层至少用两个独立连接观察锁与隔离；恢复层在新实例重放迁移、备份与恢复。只看客户端显示“Query OK”不能证明结果正确，更不能证明在另一组数据和并发时仍正确。

建议保存下面的实验记录：

项目	需要记录的证据
版本	`SELECT VERSION()` 与镜像标签
会话	sql_mode、time_zone、事务隔离与字符集
输入	schema 版本、种子行数和参数值
输出	结果集、受影响行数、警告、错误码与 SQLSTATE
性能	执行计划、实际行数、耗时与等待
恢复	COMMIT/ROLLBACK 结果、备份校验和与恢复行数

每组脚本都应能在空数据库从头执行，并通过显式断言退出非零。涉及权限时分别用管理员和最小权限账户连接；涉及锁时设置有限等待，避免测试永久挂起；涉及复制时等待 GTID 状态而不是固定 sleep。清理只删除本次创建的临时容器、网络和数据库。

本篇可以用以下目标做验收：用 ACID 分析业务原子单位；区分一致性读、锁定读和快照；比较四种隔离级别的可见性。把每个目标转换为一条可重复 SQL、一个预期错误或一项恢复检查。若优化后结果正确但计划退化，应把执行计划也纳入回归证据。

发布前再从三个方向反向审查：把数据量放大两个数量级，判断扫描、锁和日志是否仍可控；让两个会话以最不利顺序并发，判断约束和事务是否仍保护不变量；让执行在任意一步失败，判断备份、回滚或幂等键能否恢复。只在十几行数据和单连接中成功的 SQL 仍只是功能草稿。

最后把脚本交给一个只知道镜像版本和入口命令的干净环境执行。脚本不得依赖图形客户端自动设置、个人默认数据库或先前会话变量；所有对象名、字符集、事务和预期错误都应明确。对仅用于说明、不可直接执行的片段要标注上下文，避免把省略条件的示意 SQL 当作完整迁移。

还要保存一份“结果为什么可信”的说明：约束证明哪些坏数据无法进入，事务证明哪些变化共同提交，执行计划证明访问了哪些行，权限测试证明哪些身份无法越界，恢复演练证明故障后能重新得到可用状态。这五类证据缺一时，都应在结论旁写明限制。数据库实验的价值不只是得到答案，而是让另一位操作者在不同机器、不同时间仍能重现同一判断。

若结论依赖当前数据分布或配置，应把适用范围写在 SQL 旁，并安排数据增长或版本升级后的复测条件；不要把一次测量永久固化为规则。

九、StudyStore 实验

用两个连接在 READ COMMITTED 与 REPEATABLE READ 下执行同一读写序列，记录每次可见结果。实现订单与库存原子事务，制造中途约束失败和连接取消，验证订单项、库存与审计要么全部提交、要么全部回滚。

完成本节后，不要只保存代码或 SQL。请同时保存执行命令、关键输出和失败案例；学习笔记真正有价值的部分，是能够说明输入、状态变化、输出以及失败后的恢复方式。

十、常见错误

以为多条自动提交语句天然属于同一事务
把 DDL 混进希望完整回滚的业务事务
混淆普通快照读与 SELECT FOR UPDATE
在事务中调用慢远程服务或等待用户输入
死锁后只重试最后一条 SQL 而非整个事务

十一、练习与自测

用两个会话比较 READ COMMITTED 与 REPEATABLE READ。
制造订单项插入失败并证明库存未扣减。
列出一个跨 MySQL 与邮件的流程为何不满足单库事务。
设计带 request_key 的事务重试与结果查询。

自测时应在干净的临时目录或临时数据库中重新执行，而不是依赖上一节遗留的状态。如果结果与预期不同，先记录实际输出，再缩小问题范围。

十二、官方资料

版本行为与二手文章不一致时，以本系列固定版本的官方文档、命令输出和可重复测试结果为准。

上一篇：EXPLAIN、统计信息与查询优化下一篇：锁、死锁与并发控制