MySQL事务的四种特性,分别解释？｜阿里巴巴后端开发面经解析

60 秒回答模板

事务的四大特性是 ACID。原子性指一个事务内的操作要么全部成功，要么全部失败，InnoDB 通过 undo log 记录旧版本来支持回滚。隔离性指并发事务之间不能互相产生不该出现的干扰，InnoDB 通过 MVCC、ReadView、行锁、间隙锁、临键锁以及不同隔离级别来控制可见性和并发冲突。持久性指事务提交后，即使数据库崩溃，提交结果也不能丢失，InnoDB 主要依赖 redo log、刷盘策略和崩溃恢复机制。一致性指事务执行前后，数据库要从一个正确状态转到另一个正确状态，它依赖原子性、隔离性、持久性，也依赖主键、唯一键、外键、检查约束、业务规则等共同保证。补充一点，MySQL 还涉及 redo log 和 binlog 的配合：redo log 保证 InnoDB 崩溃恢复，binlog 用于复制和恢复，两者通过两阶段提交降低事务提交后存储引擎状态与 binlog 状态不一致的风险。

考点 ACID 的总体含义

主线 原子性：全部成功或全部失败

易错点 只背 ACID 四个中文名，不解释 InnoDB 的 …

深入解析

ACID 的总体含义

ACID 是事务正确性的四个维度：Atomicity 原子性、Consistency 一致性、Isolation 隔离性、Durability 持久性。面试回答不能只背定义，还要说明 MySQL/InnoDB 如何落地。简单说，原子性解决“做一半怎么办”，隔离性解决“并发互相影响怎么办”，持久性解决“提交后宕机怎么办”，一致性解决“结果是否仍满足正确规则”。

原子性：全部成功或全部失败

原子性指事务中的多个操作被当作一个不可分割的整体。只要事务失败、显式 rollback、死锁回滚或异常中断，已经执行的修改都要撤销。在 InnoDB 中，原子性主要依赖 undo log。更新一行数据时，InnoDB 会记录能把数据恢复到修改前状态的 undo 信息，例如 update 前的旧值、insert 对应的删除信息、delete 对应的恢复信息。回滚时根据 undo log 反向恢复，从而让事务表现为没有执行过。

一致性：从一个正确状态到另一个正确状态

一致性不是单纯由某个日志保证的，它是事务最终目标。数据库在事务前后都应满足约束和业务不变量，例如主键唯一、余额不能凭空增加、订单状态流转合法、外键关系有效。数据库层面的约束、触发器、外键、唯一索引、非空约束能保证一部分一致性；应用层业务逻辑负责更复杂的一致性。ACID 中其他三个特性是实现一致性的基础：没有原子性会留下半成品，没有隔离性会出现并发覆盖或错误读写，没有持久性会让已提交结果丢失。

隔离性：并发事务之间的可见性控制

隔离性指多个事务并发执行时，每个事务看到的数据应符合当前隔离级别的规则。MySQL InnoDB 通过 MVCC 和锁共同实现隔离。普通快照读通常依赖 MVCC：事务读取数据时根据 ReadView 判断某个版本是否可见，旧版本由 undo log 链提供。当前读，例如 update、delete、select ... for update、lock in share mode，则会加锁，避免并发修改造成冲突。

隔离级别

MySQL 支持四个隔离级别。读未提交可能读到未提交数据，容易出现脏读。读已提交只能读到已提交数据，避免脏读，但同一事务内两次读取可能不一致。可重复读是 InnoDB 默认隔离级别，普通快照读通过事务级 ReadView 保证同一事务内多次读取结果稳定，并结合 next-key lock 在当前读场景下抑制幻读。串行化隔离最强，事务近似串行执行，并发性能最低。需要注意，InnoDB 的可重复读并不等于所有场景都没有并发异常，快照读和当前读的规则不同。

持久性：提交后的修改不能丢

持久性指事务一旦 commit 成功，即使随后 MySQL 进程崩溃或机器异常，提交结果也应能恢复。InnoDB 主要依赖 redo log。修改数据页时，数据页可以先在 Buffer Pool 中变脏，不必立刻写回磁盘；但 redo log 会记录物理层面的重做信息。崩溃恢复时，InnoDB 根据 redo log 重放已提交或应恢复的修改，使数据页回到正确状态。刷盘策略受 innodb_flush_log_at_trx_commit 等参数影响，最强策略通常是每次提交都把 redo log 刷到磁盘，性能和可靠性之间存在权衡。

redo log、undo log、binlog 的关系

undo log 主要服务于回滚和 MVCC 版本链，支撑原子性和快照读；redo log 是 InnoDB 存储引擎日志，主要服务于崩溃恢复，支撑持久性；binlog 是 MySQL Server 层日志，主要用于主从复制、时间点恢复和审计。事务提交时 redo log 与 binlog 需要保持一致，否则可能出现引擎层已经提交但复制日志缺失，或复制日志存在但引擎层未提交的问题。MySQL 通过 redo log prepare、写 binlog、redo log commit 的两阶段提交流程，降低两类日志状态不一致的风险。

高分表达

高质量回答应从定义、InnoDB 实现、并发现象和日志关系四个层次展开。定义层说明 ACID 分别解决什么问题；实现层讲 undo log、redo log、MVCC、锁；并发层讲脏读、不可重复读、幻读及隔离级别；日志层补充 redo log 与 binlog 的职责区别和两阶段提交。这样能体现不只是背概念，而是理解 MySQL 事务在真实系统中的运行机制。

易错点

只背 ACID 四个中文名，不解释 InnoDB 的 undo log、redo log、MVCC 和锁。
把一致性误解为完全由数据库自动保证，忽略业务约束和应用逻辑。
把 undo log 和 redo log 混淆，认为 redo log 用来回滚事务。
认为 MVCC 可以替代所有锁，忽略当前读和写操作仍需要加锁。
认为可重复读一定彻底消除所有并发异常，不区分快照读和当前读。
认为事务提交后数据页必须立即写入磁盘，忽略 redo log 和 Buffer Pool 机制。
把 binlog 当成 InnoDB 的崩溃恢复日志，忽略它主要属于 Server 层并服务复制与恢复。
只讲隔离级别定义，不说明脏读、不可重复读、幻读分别对应什么并发现象。

面试官追问

undo log 和 redo log 有什么区别？

undo log 记录的是回滚所需的信息，也为 MVCC 提供历史版本；redo log 记录的是数据页修改后的重做信息，用于崩溃恢复。简单说，undo log 解决“怎么撤销”，redo log 解决“提交后怎么恢复”。

MySQL 默认隔离级别是什么？为什么？

InnoDB 默认隔离级别通常是可重复读。它在一致性和并发性能之间比较平衡，普通快照读可以在同一事务内看到稳定视图，同时配合锁机制处理当前读下的并发写入问题。

MVCC 能解决所有并发问题吗？

不能。MVCC 主要解决快照读的可见性问题，让读操作不阻塞写操作，提高并发性能。但 update、delete、select ... for update 等当前读仍需要锁来控制并发冲突。

幻读和不可重复读有什么区别？

不可重复读强调同一行数据前后读取结果变了，通常是其他事务修改或删除导致。幻读强调同一查询条件前后匹配到的记录集合变了，通常是其他事务插入了符合条件的新记录。

事务提交后数据一定马上写入数据文件吗？

不一定。InnoDB 可以先把修改写入 Buffer Pool 中的数据页，并把 redo log 按策略刷盘。即使数据页尚未落盘，只要 redo log 满足持久化要求，崩溃恢复时仍可恢复提交结果。

为什么需要 redo log 和 binlog 两阶段提交？

因为 redo log 和 binlog属于不同层，前者用于 InnoDB 崩溃恢复，后者用于复制和恢复。如果两者提交状态不一致，可能造成主库数据和复制日志不匹配。两阶段提交流程用于协调它们，使事务提交结果在恢复和复制场景中保持一致。