事务把多条读写操作包装成一个逻辑工作单元，用 ACID 约束保证业务状态从一个正确状态转移到另一个正确状态。理解事务是理解金融、订单、库存和账户系统的前提。

1. 学习定位

维度	内容
难度层级	核心机制
核心目标	先会用，再理解机制，最后能做工程取舍和故障分析
学习方法	带着业务场景看命令、SQL、数据结构、日志和运行时指标

2. 核心地图

MySQL事务
├─ ACID
├─ BEGIN
├─ COMMIT
├─ ROLLBACK
├─ 隔离级别
├─ redo log
├─ undo log
├─ 锁
└─ MVCC

3. 小章节深度讲解

下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。

3.1. ACID

是什么

ACID 是事务正确性的四个观察角度：原子性保证一组操作要么都生效要么都撤销，一致性保证业务约束不被破坏，隔离性控制并发事务互相可见的程度，持久性保证提交后的修改能在崩溃后恢复。

开发人员怎么用

开发人员要把 ACID 落到业务不变量上，例如余额不能为负、订单状态不能倒退、库存不能超卖。数据库能提供机制，但业务条件必须写进 SQL、唯一约束或状态机校验中。

运维人员怎么看

运维人员要通过 redo、undo、锁等待、长事务、binlog 和备份恢复能力观察 ACID 是否有风险。事务提交慢、回滚慢、undo 积压、复制延迟，本质上都在提醒 ACID 成本正在上升。

常见风险

常见风险是只背 ACID 名词，却在代码里把远程调用放进事务，或用先查后改破坏并发一致性。ACID 不是口号，它要靠事务边界、约束和恢复链路共同兑现。

3.2. BEGIN

是什么

BEGIN 标记显式事务开始。它会让后续语句进入同一个事务上下文，直到 COMMIT 或 ROLLBACK 结束；在非 autocommit 场景下，连接上的事务状态会持续占用资源。

开发人员怎么用

开发人员使用 BEGIN 后必须保证所有分支都能结束事务。异常、超时、提前 return、连接池归还都要特别处理，否则一个连接可能带着未提交事务回到连接池。

运维人员怎么看

运维人员要关注长事务列表、事务启动时间、活跃连接和未提交事务。很多 MDL 阻塞、undo 积压和锁等待，源头都是 BEGIN 后没有及时结束。

常见风险

常见风险是事务中夹杂 HTTP、MQ、文件处理或用户交互，导致锁和快照被外部系统延迟拖住。事务越短，数据库越安全。

3.3. COMMIT

是什么

COMMIT 表示事务提交。提交时数据库要完成约束检查、日志写入、锁释放和事务状态切换；在 InnoDB 中还涉及 redo log 与 binlog 的一致性协调。

开发人员怎么用

开发人员要理解 COMMIT 可能失败或超时，尤其在网络抖动、主从半同步、磁盘压力和死锁重试场景中。业务侧要能处理“提交结果不确定”的边界，例如通过业务流水号查询最终状态。

运维人员怎么看

运维人员要关注提交延迟、redo fsync、binlog fsync、半同步等待和磁盘 IO。提交慢不一定是 SQL 慢，也可能是刷盘或复制确认慢。

常见风险

常见风险是把 COMMIT 当成本地内存赋值。核心写链路要有幂等键、重试边界和结果确认机制，避免超时后重复下单或重复扣款。

3.4. ROLLBACK

是什么

ROLLBACK 通过 undo log 撤销当前事务未提交的修改。它不是简单删除刚才写的数据，而是沿着 undo 记录把行恢复到事务开始前的可见状态。

开发人员怎么用

开发人员要知道大事务回滚可能非常慢，因此批量任务应分批提交。不要把几十万行修改放进一个事务后寄希望于快速回滚。

运维人员怎么看

运维人员看到长时间 rollback 不应随意杀进程，要先判断事务大小、undo 压力和业务影响。强杀可能导致更长恢复过程。

常见风险

常见风险是上线脚本没有分批和检查点，一旦中途失败，ROLLBACK 时间比执行时间更长，业务窗口被彻底打穿。

3.5. 隔离级别

是什么

隔离级别 关注的是事务版本可见性。InnoDB 通过事务 ID、undo 链和 Read View 判断某个历史版本对当前语句或事务是否可见。

开发人员怎么用

开发人员要区分快照读和当前读。只展示数据可以依赖快照读，读后要更新就要使用当前读、条件更新或唯一约束保护业务不变量。

运维人员怎么看

运维人员要观察长事务、undo 表空间、history list length 和 purge 速度。版本链积压会让查询变慢，也会推迟空间回收。

常见风险

常见风险是长时间打开事务做分页导出或人工审核，导致旧版本长期不能清理，最终拖累整个实例。

3.6. redo log

是什么

redo log 是 MySQL 可靠性和复制链路中的关键日志或日志阶段。不同日志服务不同目标：崩溃恢复、逻辑复制、慢 SQL 分析、错误诊断或审计。

开发人员怎么用

开发人员要控制事务大小和写入频率，避免一次提交产生过大日志。涉及消息、缓存和外部系统时，要理解提交成功和外部可见之间的边界。

运维人员怎么看

运维人员要监控日志刷盘、磁盘空间、binlog 保留、复制 relay log、慢日志体积和错误日志。日志策略必须服务恢复目标，而不是只看默认配置。

常见风险

常见风险是日志占满磁盘导致实例不可写，或者误删 binlog 后无法做时间点恢复。

3.7. undo log

是什么

undo log 关注的是事务版本可见性。InnoDB 通过事务 ID、undo 链和 Read View 判断某个历史版本对当前语句或事务是否可见。

开发人员怎么用

开发人员要区分快照读和当前读。只展示数据可以依赖快照读，读后要更新就要使用当前读、条件更新或唯一约束保护业务不变量。

运维人员怎么看

运维人员要观察长事务、undo 表空间、history list length 和 purge 速度。版本链积压会让查询变慢，也会推迟空间回收。

常见风险

常见风险是长时间打开事务做分页导出或人工审核，导致旧版本长期不能清理，最终拖累整个实例。

3.8. 锁

是什么

事务中的锁用于保护当前读和写入的一致性。InnoDB 会根据 SQL 类型、隔离级别和索引访问路径选择记录锁、间隙锁、临键锁、共享锁或排他锁；锁不是独立概念，而是事务边界和执行计划共同作用的结果。

开发人员怎么用

开发人员要把事务写短，按固定顺序访问资源，并为死锁和锁等待超时准备可重试逻辑。更新库存、余额、状态机时，优先使用条件更新、唯一约束和版本号，而不是先查后改。

运维人员怎么看

运维人员要观察锁等待时间、长事务、阻塞链、死锁日志和慢 SQL。排查时需要回答三个问题：谁持锁、谁等待、为什么访问路径会锁到这些数据。

常见风险

常见风险是把锁等待误判为数据库性能差，只扩容不改 SQL。若事务中存在长时间远程调用、缺失索引或大范围更新，扩容也无法消除阻塞链。

3.9. MVCC

是什么

MVCC 关注的是事务版本可见性。InnoDB 通过事务 ID、undo 链和 Read View 判断某个历史版本对当前语句或事务是否可见。

开发人员怎么用

开发人员要区分快照读和当前读。只展示数据可以依赖快照读，读后要更新就要使用当前读、条件更新或唯一约束保护业务不变量。

运维人员怎么看

运维人员要观察长事务、undo 表空间、history list length 和 purge 速度。版本链积压会让查询变慢，也会推迟空间回收。

常见风险

常见风险是长时间打开事务做分页导出或人工审核，导致旧版本长期不能清理，最终拖累整个实例。

3.10. 本篇学习实验

建议准备一个至少百万行级别的测试表，分别观察正常查询、缺失索引、错误索引、长事务、锁等待和慢查询日志。每次实验都记录 SQL、执行计划、耗时、扫描行数和 MySQL 状态变量变化。

开发侧实验重点是理解 SQL 与事务边界，运维侧实验重点是理解指标如何变化。真正掌握本篇内容，应该能从现象反推 SQL、索引、锁、日志或存储引擎问题。

4. 核心机制

• 原子性依赖 undo log 回滚未完成修改，一致性依赖业务约束、数据库约束和事务共同保证。
• 隔离性由锁和 MVCC 实现，不同隔离级别在脏读、不可重复读、幻读方面表现不同。
• 持久性依赖 redo log 和刷盘策略，提交成功后即使进程崩溃也能恢复已提交修改。
• 事务越大，持锁时间越长，undo 和 redo 压力越大，对复制和故障恢复也越不友好。

5. 工程实践

• 事务范围要短，只包必要的数据库操作，不把远程调用、文件上传和人工等待放进事务。
• 涉及余额、库存、状态机的更新要有明确条件，避免无条件覆盖。
• 批量任务分段提交，控制单事务行数和日志体积。
• 应用层要正确处理提交失败、超时、死锁重试和幂等。

6. 常见坑

• 开启事务后忘记提交，长时间占用连接和锁。
• 事务中调用外部服务，导致数据库资源被网络抖动拖住。
• 认为事务能自动保证所有业务一致性，忽略唯一约束和条件更新。
• 把 autocommit 行为理解错，导致隐式提交和回滚范围不符合预期。

7. 专家视角

• 事务设计的关键是业务不变量，例如余额不能为负、订单状态不能倒退、库存不能超卖。
• 专家会优先用数据库约束和条件更新保护关键不变量，再用应用逻辑补充流程控制。
• 分布式事务不是默认选项，能通过本地事务、消息幂等和最终一致解决的，不要轻易引入重型协议。

8. Tips 快问快答

Q：事务越大越安全吗？

A：不是。大事务持锁久、日志大、回滚慢，会放大故障影响。

Q：ACID 都由数据库自动保证吗？

A：数据库提供机制，但一致性还依赖业务约束和正确的事务边界。

Q：事务里能调用 HTTP 吗？

A：原则上不要。外部调用不可控，会拖长锁时间并增加失败场景。

9. 阶段小结

MySQL事务 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。