MySQL事务底层原理：日志、锁与MVCC实战解析

MySQL事务redo log

于 2026-10-01 06:02:11 修改

·本内容遵循CC 4.0 BY-SA版权协议

直接进入正文

1. 事务到底在解决什么问题：从一条转账SQL说起

在我刚开始写业务代码那几年，对事务的理解就停在“加个@Transactional注解”这一步。直到有一天，线上订单表出现了一条金额对不上的脏数据，排查到凌晨三点，最后发现是并发提交时隔离级别没搂住。从那天起，我决定把MySQL事务的底层原理彻底啃一遍，不再指望背面试题活着。

事务这个概念，本质上回答的是一个问题：多个SQL语句作为一个整体执行时，数据库怎么保证它们“要么全成功、要么全失败”，并且在并发场景下互不干扰。

拿转账举例，A账户扣100元、B账户加100元，这两条SQL必须绑定在一起。如果第一步执行完、第二步还没执行时数据库突然宕机，重启后A的钱扣了、B的钱没到账，这笔账就永远对不上了。事务机制就是给这种场景兜底的。

1.1 为什么ACID缺一不可

事务的四大特性——原子性、一致性、隔离性、持久性——经常在面试题里出现，名字背得熟，但真正把它们和底层机制对应上的人不多。我整理了一个对应关系表：

特性	解决的问题	MySQL底层实现
原子性	多个操作要么全执行、要么全不执行	undo log回滚日志
一致性	事务执行前后数据总量保持完整约束	应用层逻辑+约束+原子性隔离性共同保证
隔离性	并发事务之间互不干扰	锁机制 + MVCC多版本并发控制
持久性	事务提交后数据不丢失	redo log重做日志

这几个特性不是孤立的。原子性是基础，它靠undo log把已执行的SQL逆操作回去；持久性是底线，它靠redo log把内存中的脏页在崩溃后重建出来；隔离性是并发场景下的核心战场，它由锁和MVCC协同完成；一致性更像一个结果指标，前面三个做好了，数据自然能保持一致。

1.2 从业务场景反推事务的本质需求

想真正理解事务，不能只盯着数据库内部看，还得回到业务现场。电商下单就是一个典型的多步操作：扣减库存、生成订单、锁定优惠券、记录流水。这些操作分散在不同表里，有的还要调远程服务。如果扣库存成功但生成订单失败，库存就凭空少了一件，这就是不一致。

从业务视角反推，事务需要做到三件事：第一，失败时要能撤销已经做过的操作；第二，多个用户同时操作同一条数据时不能互相踩踏；第三，系统崩溃后数据仍然能恢复到一个合理状态。MySQL的底层设计完全是围绕这三个需求展开的，后面讲的日志、锁、MVCC，每个组件都能对应到具体的业务痛点。

1.3 事务在MySQL中的执行起点

MySQL中一条标准的事务操作大概长这样：

SQL

START TRANSACTION;

UPDATE account SET balance = balance - 100 WHERE user_id = 1;

UPDATE account SET balance = balance + 100 WHERE user_id = 2;

COMMIT;

如果是出错了，就把COMMIT换成ROLLBACK。这种方式叫显式事务，也是生产环境中唯一推荐的方式。像autocommit这种默认开启的隐式事务模式，每条SQL独立成事务，在批量导数据时容易踩坑——插一半失败了，前面成功的记录不会自动回滚。

提示：在业务代码里使用事务注解时，要注意事务的边界。事务不是越长越好，长事务会占用连接、锁资源，还会导致undo log膨胀，后面我会详细展开。

2. 底层三兄弟：redo log、undo log、binlog

MySQL事务底层原理的核心，就是围绕三类日志展开的。我一直把它们称为“三兄弟”，因为它们分工不同、配合紧密，缺一个都不行。

2.1 redo log：崩溃恢复的救命稻草

redo log解决的是持久性问题。InnoDB引擎的数据默认是存在内存的Buffer Pool里的，如果每次提交都直接写磁盘数据文件，随机IO的性能瓶颈会让人绝望。但如果不写磁盘，宕机时内存数据就全没了。redo log就是中间那个缓冲层。

它的写入机制是顺序IO。内存中的数据页修改后，先把这个修改记录追加到redo log中，当事务提交时，再把redo log刷到磁盘。因为日志是追加写的，顺序IO比随机IO快一个数量级，所以性能损耗可控。等系统空闲时，后台线程再把内存中的脏页异步刷入真正的数据文件，这个过程叫checkpoint。

这里有一个关键参数叫innodb_flush_log_at_trx_commit，它有三个取值：

参数值	行为	崩溃时可能丢失的数据
0	每秒刷一次磁盘	最多丢1秒数据
1	每次事务提交都刷磁盘	不丢数据
2	每次提交先写操作系统缓存，每秒刷磁盘	操作系统崩溃时最多丢1秒数据

生产环境建议设成1，数据安全优先。对性能有极致追求且能容忍丢1秒数据的场景，可以设成2，但绝不要设成0。

2.2 undo log：回滚和MVCC的基石

undo log解决的是原子性问题，但它做的事情比网上很多文章写的要更丰富。每执行一条写操作，InnoDB都会生成一条反向操作记录写入undo log。如果是INSERT，就记一条DELETE的undo；如果是UPDATE，就记一条UPDATE回原值的undo。

事务执行到一半要回滚时，就顺着undo log把操作逐条反向执行。但这只是undo log的其中一个功能，它还有一个更重要的角色——MVCC多版本控制的版本链。每一行数据上的隐藏列DB_ROLL_PTR会指向undo log中的历史版本，这样不同事务可以读到不同时间点的数据快照。这个功能我在第4章会详细展开。

需要注意一个经典坑：undo log不是事务一结束就立刻删除的。如果有其他事务正在读取旧版本数据，undo log必须保留。长事务或长时间不提交的事务，会导致undo log不断累积，占满undo表空间，这就是“undo膨胀”问题。

2.3 binlog：归档和主从复制的底层依赖

redo log和undo log是InnoDB存储引擎层的日志，binlog则是MySQL Server层的日志，它跟选什么存储引擎无关。binlog记录了所有改变数据库内容的操作，包括表结构变更和数据变更，它的作用有两个：主从复制和数据恢复。

binlog有三种记录格式：STATEMENT记录SQL原文；ROW记录每行数据的前后镜像；MIXED是前两种的混合策略。从MySQL 5.7.7开始，默认格式改成了ROW。ROW格式虽然日志量大，但胜在准确，能避免一些函数或存储过程在不同机器上执行结果不一致的问题。

sync_binlog参数控制binlog的刷盘策略，默认是1，表示每次事务提交都刷盘。这个参数和innodb_flush_log_at_trx_commit=1配合使用，是保证数据不丢的标准配置。

2.4 三个日志怎么配合：写盘时机与刷盘策略

三个日志的分工和协作关系，我用一条UPDATE语句来串一遍：

当你执行UPDATE account SET balance = 100 WHERE id = 1时：

将id=1这行数据从磁盘加载到Buffer Pool，如果已经在内存中就直接用；
把原来那行数据写入undo log，用来做回滚和版本链；
在Buffer Pool中修改数据，此时内存中数据和磁盘不一致，这一页变成脏页；
生成redo log，记录“在哪个页的哪个偏移量改成了什么值”，状态为PREPARE；
生成binlog，记录这条SQL语句或行变更，状态为COMMIT；
事务提交时，依次刷盘redo log和binlog；
后台线程在合适时机将脏页刷入磁盘数据文件。

这一步一步走下来，每个日志都有自己的节奏，但最终一起保证了事务的四大特性。

3. 事务隔离级别与锁：并发控制的第一道闸门

事务并发执行时，如果不加任何保护，会出现三类问题：脏读、不可重复读、幻读。MySQL用隔离级别来划分这些问题的容忍度，用锁机制来实现隔离。

3.1 四种隔离级别分别解决了什么问题

SQL标准定义了四种隔离级别，MySQL InnoDB对这四种级别都有对应实现：

隔离级别	脏读	不可重复读	幻读
READ UNCOMMITTED（读未提交）	可能发生	可能发生	可能发生
READ COMMITTED（读已提交）	不会发生	可能发生	可能发生
REPEATABLE READ（可重复读）	不会发生	不会发生	可能发生（InnoDB已解决）
SERIALIZABLE（串行化）	不会发生	不会发生	不会发生

这里有个容易搞混的点：MySQL默认隔离级别是REPEATABLE READ，但InnoDB通过间隙锁和MVCC解决了幻读问题，所以实际上它在RR级别下幻读也不会发生。这是InnoDB和标准SQL的一个典型差异，也是面试里最喜欢的追问方向。

生产中90%以上的场景RR级别就够了。READ COMMITTED适合对一致性要求不那么苛刻、但对并发性能要求很高的系统；SERIALIZABLE基本不推荐，它把所有并发操作退化成串行，性能代价太大。

3.2 锁的粒度与类型：行锁、间隙锁、临键锁

InnoDB的锁是建立在索引上的，这是理解锁机制的关键。根据锁定的范围，分为三种：

记录锁（Record Lock）：锁住单个索引记录；
间隙锁（Gap Lock）：锁住一个范围，但不包括记录本身，目的是阻止其他事务在这个范围内插入新数据；
临键锁（Next-Key Lock）：是记录锁+间隙锁的组合，锁住一个范围及范围内的记录。

间隙锁和临键锁是InnoDB解决幻读的关键。举个例子，事务A执行了SELECT * FROM t WHERE id > 10 FOR UPDATE，如果id 15和20有数据，InnoDB会锁住(10, 15]、(15, 20]、(20, +∞)这几个区间。这时候事务B想在id 12插入数据，会被阻塞，因为那正好在事务A锁定的间隙里。

我之前在生产环境吃过一次大亏：业务表删除数据时，明明只删一条，却因为索引设计不合理，间隙锁把整个范围的写入全堵住了，请求直接堆积到报警。排查后发现是WHERE条件没用索引，导致锁从行锁升级成了全表范围的锁。

注意：如果UPDATE或DELETE语句的WHERE条件没有命中索引，InnoDB会锁定所有扫描到的记录。这在实际生产中是最常见的锁惨案来源，务必养成用EXPLAIN检查执行计划的习惯。

3.3 生产环境下怎么选隔离级别

选隔离级别不是纯技术上能做决定的，要结合业务场景和监控数据。给一个参考流程：

默认从REPEATABLE READ开始，它是MySQL的默认配置，对大多数OLTP业务都够用；
查看慢查询和锁等待监控，如果发现间隙锁导致的锁冲突明显，再考虑切到READ COMMITTED；
用performance_schema和sys.innodb_lock_waits观察锁等待情况，拿数据说话，不要拍脑袋改配置；
改配置用SET GLOBAL transaction_isolation = 'READ-COMMITTED';，但注意这只对新连接生效，必要时还要在连接池层面调整。

我遇到过很多团队把隔离级别当成性能开关，遇到锁等待就切READ COMMITTED，结果脏数据出得比之前更快。隔离级别和锁是数据库一致性的防线，改之前务必搞清楚业务上能容忍什么问题，不能容忍什么问题。

4. MVCC多版本并发控制实战拆解

MVCC（Multi-Version Concurrency Control）是InnoDB实现隔离性的核心机制，也是面试中最容易卡住人的部分。可以把它理解成：同一行数据在内存里保留了多个历史版本，不同事务各看各的快照，读写互不阻塞。

4.1 隐藏列与版本链

每行数据除了业务字段，还有三个隐藏列：

DB_TRX_ID：最近一次对这行数据做修改的事务ID；
DB_ROLL_PTR：指向undo log中该行历史版本的指针；
DB_ROW_ID：如果没有指定主键，InnoDB用它生成隐藏主键。

当一行数据被多次修改时，undo log会串成一个链表。比如id=1的账户初始余额是100，事务A把它改成200，事务B又把它改成300，这条数据的版本链就是这样的：

TEXT

当前值300 <-- 版本200 <-- 版本100

每个版本都记录了自己是被哪个事务改的。当另一个事务来读这行数据时，它按照规则判断哪个版本对它可见。这个规则的核心就是ReadView。

4.2 ReadView的生成时机

ReadView可以理解成一个“事务快照的观察窗口”，它记录了四个重要字段：

m_ids：生成ReadView时当前活跃的事务ID列表；
min_trx_id：最小的活跃事务ID；
max_trx_id：下一个将被分配的事务ID，注意不是最大的活跃事务ID，而是边界值；
creator_trx_id：生成这个ReadView的事务自己的ID。

判断一条数据版本是否可见的规则可以归纳成三句话：

如果版本的事务ID小于min_trx_id，说明这个版本在ReadView生成前就已经提交了，可见；
如果版本的事务ID大于等于max_trx_id，说明这个版本是ReadView生成后开启的事务修改的，不可见；
如果版本的事务ID在min_trx_id和max_trx_id之间，要检查它是否在m_ids中。在就说明还没提交，不可见；不在就说明已经提交了，可见。

如果某个版本不可见，就顺着DB_ROLL_PTR指针继续找上一个版本，直到找到可见版本或者到达链表头。

4.3 快照读与当前读：为什么有时读不到刚提交的数据

MVCC带来一个重要的概念区分：快照读和当前读。

普通的SELECT语句是快照读，它使用MVCC机制，不加锁，读到的是ReadView对应的历史版本。在REPEATABLE READ级别下，事务第一次执行SELECT时生成ReadView，之后整个事务期间都复用这个ReadView，所以事务内多次查询结果一致。

SELECT ... FOR UPDATE、INSERT、UPDATE、DELETE是当前读，它读取的是数据的最新版本，并且会对读取的记录加锁。这就是为什么同一个事务里，用普通SELECT能查到数据，但升级成FOR UPDATE后就被锁阻塞了。

我在实际业务里遇到过一个经典问题：在一个事务里，先查了一次库存，确认有货，然后执行扣减，但在并发场景下库存被别的任务扣成负数了。原因就是查询用了快照读，看到的还是旧数据，而扣减用的UPDATE是当前读，它不会拿快照去判断库存。解决办法是直接用UPDATE ... SET stock = stock - 1 WHERE id = ? AND stock >= 1这种带条件的原子操作，或者把查询改成SELECT ... FOR UPDATE。

5. 原子性的最后一道保障：两阶段提交与崩溃恢复

redo log保证InnoDB自己的持久性，binlog保证Server层的数据完整，但如果这两者写盘了其中一个、另一个没写盘，数据还是会出现不一致。MySQL通过两阶段提交把这两个日志的写入过程协调起来，这其实是事务原子性在日志层面的最后一道保障。

5.1 redo log与binlog的“分布式一致”问题

想象一个崩溃场景：事务已经写完了redo log并刷盘，但binlog还没来得及写，或者写了一半，数据库就挂了。恢复时，InnoDB发现redo log里该事务是已提交状态，就把数据恢复了。但主从复制依赖的是binlog，从库没有收到这个事务，数据就和主库不一致了。

反过来也一样：binlog已经写完了，但redo log还没标记为最终提交，崩溃恢复时InnoDB判定事务未提交需要回滚，主库没这数据，但binlog已经发给从库了，从库多执行了一个事务。

所以要解决的就是一个类似“分布式事务”里的一致性问题：两个独立的日志系统，如何做到要么都成功、要么都失败。

5.2 prepare、commit两阶段到底怎么走

InnoDB的两阶段提交是这样执行的：

阶段一（prepare）：事务执行完所有写操作，生成redo log并写入磁盘，此时redo log状态打上PREPARE标记。

阶段二（commit）：将事务的binlog写入磁盘，然后在redo log中把事务状态更新为COMMIT。

如果事务在prepare之后、binlog写入之前崩溃，恢复时发现redo log里是PREPARE状态，但binlog里没有对应事务，判定该事务需要回滚，清除相关数据页的修改。

如果事务在binlog写入完成之后崩溃，恢复时发现redo log里是PREPARE状态，且binlog里有完整的事务记录，判定该事务可以提交，补上COMMIT标记。

这套流程保证了redo log和binlog中事务状态的强一致，是崩溃恢复正确性的根基。

5.3 崩溃后怎么判断事务该提交还是回滚

MySQL崩溃后重启的恢复过程叫做崩溃恢复。InnoDB在恢复时会扫描redo log，找出所有处于PREPARE状态但还没有标记COMMIT的事务，然后逐个检查binlog，看这些事务是否已经完整写入binlog。

如果binlog里存在完整记录，走提交动作；如果不存在，走回滚动作。这也是为什么sync_binlog=1那么重要：如果binlog还没来得及刷盘就崩溃了，事务就会按未提交处理，这和保护机制的预期是一致的。

数据恢复的完整链路还要考虑存储层面的备份。我建议每个MySQL实例都配置好全量备份+binlog归档，这样才能在极端情况下做到完全不丢数据。binlog就是“可恢复的时间轴”，日常运维里定期验证备份可恢复性，是比任何参数调优都重要的事。

6. 常见问题与排查技巧实录

讲了这么多原理，最后落地到实际操作。下面这些是我在生产环境里踩过坑、也验证过有效的问题排查方法。

6.1 死锁排查：show engine innodb status怎么看

死锁是事务场景最容易遇到的问题。两个事务各自持有一把锁，同时等待对方释放另一把锁，就形成了死锁。InnoDB默认会通过死锁检测机制自动回滚代价较小的事务，让另一个事务继续执行。

排查死锁最直接的方法是执行：

SQL

SHOW ENGINE INNODB STATUS;

看输出中LATEST DETECTED DEADLOCK部分的内容，那里会详细记录死锁涉及的两条事务正在执行的SQL、持有的锁和等待的锁。标准排查步骤：

根据输出定位两个事务执行的SQL语句；
分析它们加锁的顺序，找出“A等B、B等A”的关键路径；
调整业务代码，让所有事务以相同顺序访问表和行；
尽量缩小事务范围，缩短持锁时间；
把大事务拆小，避免一个事务操作成千上万行数据。

如果系统里死锁频繁，可以先看监控里的死锁次数，再针对性看INFORMATION_SCHEMA.INNODB_TRX找出活跃的长事务。

6.2 长事务与undo膨胀监控

长事务是很多隐藏问题的根源。事务长时间不提交，会导致锁不释放、undo log无法清理、连接资源占用，还会让基于MVCC的历史版本链越拉越长，其他事务的查询性能也会跟着下降。

查当前所有活跃事务用这条SQL：

SQL

SELECT trx_id, trx_state, trx_started, trx_rows_locked, trx_rows_modified

FROM information_schema.innodb_trx;

trx_started字段显示了事务开始时间，如果发现某个事务已经活跃了好几分钟甚至几小时，必须立刻定位它对应的线程和执行中的SQL。在慢查询日志和processlist里都能找到线索。我还习惯在业务代码里给事务设超时时间，防止漏提交的极端情况。

undo膨胀的排查可以查看undo表空间大小：

SQL

SELECT TABLESPACE_NAME, FILE_SIZE / 1024 / 1024 AS size_mb

FROM information_schema.FILES

WHERE TABLESPACE_NAME LIKE '%undo%';

如果undo空间持续增长且无法收缩，大概率是有长事务在挡路。杀掉那些长事务之后，undo空间会在purge线程逐步清理后回落。

6.3 隔离级别的实际测试方法

理论讲再多，不如动手验证一次。我经常在培训时用两个终端窗口做演示：

终端A开启一个事务，插入一条数据但不提交：

SQL

START TRANSACTION;

INSERT INTO test_user(name) VALUES ('zhangsan');

终端B分别在不同隔离级别下查询：

SQL

SET SESSION transaction_isolation = 'READ-UNCOMMITTED';

SELECT * FROM test_user WHERE name = 'zhangsan';

把隔离级别依次改成READ-COMMITTED、REPEATABLE-READ，再执行同样的查询，就能直观看到脏读和不可重复读的区别。测试幻读则要配合当前读，比如在两个会话里同时执行SELECT * FROM test_user WHERE id > 10 FOR UPDATE，然后尝试插入新数据，观察锁阻塞的效果。

这种动手测试远比背概念印象深刻，也能帮你理解间隙锁到底“卡”在哪里。

6.4 分布式事务场景的扩展思考

MySQL本身的事务只能覆盖单数据库。当业务拆成微服务，一个操作要跨多个数据库甚至多个中间件时，就需要引入分布式事务方案。常见的方案有：

方案	核心思想	适用场景
基于消息队列的事务消息	本地事务和消息发送绑定	异步解耦场景
TCC（Try-Confirm-Cancel）	预留资源、确认、补偿	强一致性要求高的场景
Seata AT模式	通过代理层解析SQL，生成前后镜像做补偿	改造量小，适合已有服务

以Seata为例，它借鉴了MySQL事务的设计思路：全局事务ID贯穿所有参与方，每个分支事务的SQL提交时并不真正提交本地事务，而是记录UNDO_LOG（业务表的镜像日志），在全局事务确认提交时才真正提交，需要回滚时通过UNDO_LOG做反向补偿。这个思想跟InnoDB的undo log有异曲同工之处，理解了MySQL事务底层原理，再去看分布式事务的补偿机制会容易很多。

7. 把原理转化成能力

MySQL事务的底层原理，掰开揉碎就是日志、锁、MVCC这三件事。redo log和binlog的两阶段提交解决了原子性和持久性，undo log撑起回滚和版本链，锁和MVCC解决了并发隔离。每一条技术点背后都对应一个具体的故障场景和业务痛点，理解了这个对应关系，你才算真正掌握它。

我个人在实际工作中最大的体会是：不要等到出了问题才回来翻原理。每次写事务代码、调SQL时，脑子里过一遍这三个问题——这条数据会被并发操作吗？事务会不会开得太久？崩溃后会丢数据吗？——就能避开大部分坑。MySQL这条路很宽也很深，事务是先啃下来的一块硬骨头，啃完之后再看锁、看优化器、看主从复制，都会轻松很多。