原子性Atomicity是数据库事务的ACID特性之一指一个事务中的所有操作要么全部成功执行并提交要么在发生错误时全部回滚、不留下任何部分执行的痕迹确保数据的一致性和完整性。例如在银行转账场景中从账户A扣款和向账户B加款必须作为一个不可分割的整体完成若中途失败如网络中断或余额不足整个事务将被撤销A和B的账户状态保持原样。在InnoDB存储引擎中原子性主要通过undo log回滚日志与事务的两阶段提交机制协同实现。其核心思想是在事务执行过程中任何数据修改INSERT/UPDATE/DELETE前InnoDB会先将修改前的原始数据即“前镜像”写入undo log并持久化到磁盘受innodb_flush_log_at_trx_commit等参数影响。这样即使事务中途失败或被显式回滚ROLLBACK系统可通过undo log反向还原每一步操作将数据恢复至事务开始前的一致状态。具体流程如下执行阶段事务T对某行记录做UPDATE时InnoDB先将该行原值含主键、列值、事务ID等写入undo log分配undo slot生成undo record再在内存Buffer Pool中修改数据页并标记为“脏页”同时记录对应的redo log用于崩溃恢复保障持久性。提交阶段若事务成功写入commit标记到redo log并刷盘确保持久性undo log则被标记为“可清理”但暂不立即删除因可能被其他事务用于MVCC快照读。回滚阶段若事务未提交而异常终止如客户端断开、执行ROLLBACKInnoDB根据undo log中保存的前镜像按逆序逐条执行反向操作如INSERT的逆操作是DELETEUPDATE的逆操作是用旧值覆盖从而撤销所有已做的修改保证“全不做”。值得注意的是undo log本身也受事务保护即写undo log的操作也需写redo log形成嵌套保障且InnoDB的undo log存储在共享表空间或独立undo tablespace中支持多版本并发控制MVCC和事务隔离。在InnoDB中undo log和redo log是保障事务ACID特性的两大核心日志机制分工明确、协同工作缺一不可undo log回滚日志承担角色主要支撑原子性Atomicity和一致性Consistency同时为多版本并发控制MVCC提供历史版本数据。作用原理记录事务修改前的数据“快照”前镜像用于事务回滚ROLLBACK或异常崩溃后撤销未提交的更改在可重复读RR隔离级别下还供其他事务读取一致性视图consistent read。特点逻辑日志记录“如何撤销”可被覆盖重用生命周期与事务及MVCC快照绑定。redo log重做日志承担角色主要保障持久性Durability和原子性Atomicity的崩溃恢复基础。作用原理记录事务对数据页所做的物理修改如“将页X偏移Y处的值从A改为B”采用WALWrite-Ahead Logging机制——即先写redo log再刷脏页。即使系统崩溃重启后可通过重放redo log将已提交但尚未写入磁盘的数据页恢复至最新一致状态。特点物理日志记录“做了什么修改”循环写入ring buffer必须持久化到磁盘才能确认事务提交受innodb_flush_log_at_trx_commit1约束。✅为何二者缺一不可仅有redo log→ 可保证已提交事务不丢失持久性但无法回滚未提交事务无前镜像破坏原子性也无法支持MVCC快照读影响并发一致性。仅有undo log→ 可回滚、支持快照读但若崩溃时脏页未刷盘、redo未写入重启后数据页可能丢失或处于中间状态无法恢复已提交事务违反持久性。协同关系提交时先确保redo log刷盘持久化修改再标记事务提交undo log此时仅标记为“可清理”不立即删除因MVCC需保留旧版本回滚时依赖undo log还原而undo log自身的修改也受redo log保护即写undo也要记redo形成日志保护链崩溃恢复时先重放redo log前滚恢复所有已提交/未提交的物理变更再根据事务状态通过redo中的事务表决定是否用undo log回滚未提交事务后滚最终达成原子持久的一致状态。简言之redo log负责“故障后把事情做完”undo log负责“出错时把事情抹掉”——二者共同构成InnoDB事务可靠性的双支柱。 
长河君 · 2026/8/16 23:18:43 · 阅读 1.2k 原子性（Atomicity）是数据库事务的ACID特性之一，指一个事务中的所有操作要么全部成功执行并提交
原子性Atomicity是数据库事务的ACID特性之一指一个事务中的所有操作要么全部成功执行并提交要么在发生错误时全部回滚、不留下任何部分执行的痕迹确保数据的一致性和完整性。例如在银行转账场景中从账户A扣款和向账户B加款必须作为一个不可分割的整体完成若中途失败如网络中断或余额不足整个事务将被撤销A和B的账户状态保持原样。在InnoDB存储引擎中原子性主要通过undo log回滚日志与事务的两阶段提交机制协同实现。其核心思想是在事务执行过程中任何数据修改INSERT/UPDATE/DELETE前InnoDB会先将修改前的原始数据即“前镜像”写入undo log并持久化到磁盘受innodb_flush_log_at_trx_commit等参数影响。这样即使事务中途失败或被显式回滚ROLLBACK系统可通过undo log反向还原每一步操作将数据恢复至事务开始前的一致状态。具体流程如下执行阶段事务T对某行记录做UPDATE时InnoDB先将该行原值含主键、列值、事务ID等写入undo log分配undo slot生成undo record再在内存Buffer Pool中修改数据页并标记为“脏页”同时记录对应的redo log用于崩溃恢复保障持久性。提交阶段若事务成功写入commit标记到redo log并刷盘确保持久性undo log则被标记为“可清理”但暂不立即删除因可能被其他事务用于MVCC快照读。回滚阶段若事务未提交而异常终止如客户端断开、执行ROLLBACKInnoDB根据undo log中保存的前镜像按逆序逐条执行反向操作如INSERT的逆操作是DELETEUPDATE的逆操作是用旧值覆盖从而撤销所有已做的修改保证“全不做”。值得注意的是undo log本身也受事务保护即写undo log的操作也需写redo log形成嵌套保障且InnoDB的undo log存储在共享表空间或独立undo tablespace中支持多版本并发控制MVCC和事务隔离。在InnoDB中undo log和redo log是保障事务ACID特性的两大核心日志机制分工明确、协同工作缺一不可undo log回滚日志承担角色主要支撑原子性Atomicity和一致性Consistency同时为多版本并发控制MVCC提供历史版本数据。作用原理记录事务修改前的数据“快照”前镜像用于事务回滚ROLLBACK或异常崩溃后撤销未提交的更改在可重复读RR隔离级别下还供其他事务读取一致性视图consistent read。特点逻辑日志记录“如何撤销”可被覆盖重用生命周期与事务及MVCC快照绑定。redo log重做日志承担角色主要保障持久性Durability和原子性Atomicity的崩溃恢复基础。作用原理记录事务对数据页所做的物理修改如“将页X偏移Y处的值从A改为B”采用WALWrite-Ahead Logging机制——即先写redo log再刷脏页。即使系统崩溃重启后可通过重放redo log将已提交但尚未写入磁盘的数据页恢复至最新一致状态。特点物理日志记录“做了什么修改”循环写入ring buffer必须持久化到磁盘才能确认事务提交受innodb_flush_log_at_trx_commit1约束。✅为何二者缺一不可仅有redo log→ 可保证已提交事务不丢失持久性但无法回滚未提交事务无前镜像破坏原子性也无法支持MVCC快照读影响并发一致性。仅有undo log→ 可回滚、支持快照读但若崩溃时脏页未刷盘、redo未写入重启后数据页可能丢失或处于中间状态无法恢复已提交事务违反持久性。协同关系提交时先确保redo log刷盘持久化修改再标记事务提交undo log此时仅标记为“可清理”不立即删除因MVCC需保留旧版本回滚时依赖undo log还原而undo log自身的修改也受redo log保护即写undo也要记redo形成日志保护链崩溃恢复时先重放redo log前滚恢复所有已提交/未提交的物理变更再根据事务状态通过redo中的事务表决定是否用undo log回滚未提交事务后滚最终达成原子持久的一致状态。简言之redo log负责“故障后把事情做完”undo log负责“出错时把事情抹掉”——二者共同构成InnoDB事务可靠性的双支柱。