MySQL事务底层靠redo log、undo log和锁机制协同实现：redo log保障持久性，undo log支持回滚与MVCC，行锁+间隙锁实现并发控制；原子性由undo log保证，非内存回滚。
MySQL 事务的底层实现不依赖“魔法”，而是靠 redo log、undo log 和 锁机制 三者协同完成，其中 redo log 保证持久性（crash-safe），undo log 支持回滚和 MVCC，并发控制则由 行锁 + 间隙锁 等在 InnoDB 引擎内实现。
事务原子性靠 undo log 实现，不是靠内存回滚
很多人误以为事务回滚只是把内存里改过的数据“撤回来”。实际上，InnoDB 在事务修改记录前，会先将原值写入 undo log。一旦执行 ROLLBACK，就用这些旧值覆盖当前版本；即使事务已提交但崩溃重启，undo log 还能用于构建一致性视图（MVCC）。
-
undo log存在rollback segment中，属于逻辑日志（记录“怎么反向操作”），不是物理备份 - 长事务会阻止
undo log回收，导致ibdata1文件持续膨胀，这是线上常见磁盘告警根源 -
INSERT产生的undo log最简（只需记录DELETE操作），而UPDATE和DELETE会产生更复杂的版本链
持久性不靠刷脏页，靠 redo log 的两阶段写入
事务提交时，InnoDB 并不立即将 buffer pool 中的脏页写回磁盘（太慢），而是把修改操作记入 redo log，并确保该日志落盘（fsync）。只要 redo log 完整，崩溃后就能重放日志恢复未刷盘的数据。
-
innodb_flush_log_at_trx_commit=1：每次COMMIT都fsync，最安全但有性能开销；设为0或2会丢事务（最多丢 1 秒） -
redo log是固定大小的循环文件（如ib_logfile0/ib_logfile1），写满会触发checkpoint，推动脏页刷新 - 如果
redo log写失败（比如磁盘只读），事务会直接报错ERROR 1030 (HY000): Got error -1 from storage engine
可重复读隔离级别下，快照读不加锁，但幻读仍需间隙锁拦截
MySQL 默认的 REPEATABLE READ 隔离级别下，普通 SELECT 是快照读（基于 read view 读取事务开始时的已提交版本），不加锁；但当前读（如 SELECT ... FOR UPDATE、UPDATE、DELETE）会加行锁+间隙锁，防止其他事务插入“幻行”。
