事务一致性由innodb引擎实现，通过undo log、redo log、行级锁和mvcc保障acid；myisam不支持事务；需显式指定engine=innodb并确认配置，redo log确保crash-safe，undo log支持回滚与mvcc，两阶段提交协调binlog与redo log一致性。
事务一致性由存储引擎层实现，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。这个机制要求 sync_binlog=1 和 innodb_flush_log_at_trx_commit=1 配合才真正可靠。
最容易被忽略的是：只调高 innodb_flush_log_at_trx_commit 却没同步设置 sync_binlog，主库 crash 后可能出现 binlog 有记录但数据没提交，导致从库多执行一条语句。
