mysql存储引擎如何保证事务一致性_mysql执行原理解析

来源：这里教程网时间：2026-02-28 20:49:21 作者：

事务一致性由存储引擎层实现，InnoDB 是唯一默认支持完整 ACID 的引擎

MySQL 本身不管理事务，事务的原子性、一致性、隔离性、持久性（ACID）全部依赖底层存储引擎。MyISAM 不支持事务，

START TRANSACTION

和

ROLLBACK

对它完全无效；只有 InnoDB 通过回滚段（undo log）、重做日志（redo log）、行级锁和 MVCC 共同保障一致性。

常见误判是认为“开了事务就一定一致”——实际如果表用的是

MyISAM

引擎，哪怕显式写了

BEGIN

，崩溃后部分更新仍会残留，无法回滚。

建表时务必显式指定：
ENGINE=InnoDB
，不要依赖默认值（旧版本或自定义配置下可能不是）
SHOW CREATE TABLE t1
中确认
ENGINE=InnoDB
，而非
ENGINE=MyISAM
或
ENGINE=MEMORY
迁移老表时，用
ALTER TABLE t1 ENGINE=InnoDB
转换，注意该操作会锁表且重建数据

redo log 保证 crash-safe：写入失败时靠它恢复未刷盘的事务

InnoDB 把事务变更先写入内存 buffer pool，再异步刷到磁盘 data file。但断电会导致内存中已提交但未落盘的数据丢失——

redo log

就是为解决这个问题：它以顺序、固定大小（默认 48MB）、循环覆盖方式记录物理页修改，确保崩溃重启后能重放（replay）已提交但未写入 data file 的操作。

关键点在于：

redo log

是 WAL（Write-Ahead Logging）机制的核心，它必须在事务

COMMIT

前刷盘（受

innodb_flush_log_at_trx_commit

控制），否则就失去 crash-safe 能力。

innodb_flush_log_at_trx_commit = 1
（默认）：每次
COMMIT
都
fsync
到磁盘，强一致性，性能略低
=0
：每秒刷一次，崩溃可能丢失 1 秒内已提交事务
=2
：每次
COMMIT
写入 OS cache，不
fsync
，OS 崩溃会丢数据

undo log 支持回滚和 MVCC：同一行如何让不同事务看到不同版本

当事务修改某行，InnoDB 不直接覆盖原数据，而是在 undo log 中保存旧值，并在当前行记录指向 undo log 的指针（

DB_ROLL_PTR

）。这样：

ROLLBACK
时，顺着
DB_ROLL_PTR
找到前镜像，恢复即可其他事务按自己的事务 ID（
TRX_ID
）和行的
DB_TRX_ID
、
DB_ROLL_PTR
判断该版本是否可见（MVCC 可见性规则）长期不提交的大事务会阻塞 undo log 清理，导致
ibdata1
文件持续膨胀

典型现象：

SELECT

明明没加锁，却因 MVCC 版本链过长拖慢查询；或者

SHOW ENGINE INNODB STATUS

里看到

History list length

持续上升，说明 purge 线程跟不上 undo 生成速度。

两阶段提交（2PC）协调 binlog 与 redo log，避免主从不一致

MySQL 开启

binlog

后，为了保证主库 crash 后 binlog 和引擎数据一致，Server 层和 InnoDB 协作执行 2PC：

Prepare 阶段：InnoDB 将事务状态设为
TRX_STATE_PREPARED
，写入
redo log
并
fsync
Write binlog 阶段：Server 层将事务写入
binlog
并
fsync
Commit 阶段：InnoDB 将事务状态改为
TRX_STATE_COMMITTED
，并清理 undo

如果 crash 发生在 prepare 之后、binlog 写入之前，重启后 InnoDB 发现 prepare 但无对应 binlog，直接回滚；如果 crash 在 binlog 写入之后、commit 之前，重启后发现 prepare 且有 binlog，则继续 commit。这个机制要求