InnoDB通过MVCC、Undo Log、Redo Log和锁机制协同实现ACID：Undo Log保障原子性与一致性，Redo Log确保持久性，MVCC+行锁支撑隔离性，两阶段提交维护Redo Log与Binlog一致性。
InnoDB 通过多版本并发控制（MVCC）、Undo Log、Redo Log 和锁机制共同实现事务的 ACID 特性。它不依赖单一组件，而是将日志、内存结构和磁盘持久化协同工作，确保事务的原子性、一致性、隔离性和持久性。
Undo Log：保障事务原子性与一致性
每次修改数据前，InnoDB 先把旧值写入 Undo Log。若事务中途回滚，就用这些旧值“倒带”恢复；若事务提交后被其他事务读取（如可重复读隔离级别），也靠 Undo Log 构建历史快照。
- Undo Log 存储在共享表空间或独立 undo 表空间中，按段（segment）管理
- 每个事务有专属的 rollback segment，记录其所有修改的反向操作
- 长期未提交的事务会阻碍 Undo Log 回收，可能引发空间膨胀或 purge 延迟
Redo Log：确保事务持久性
事务提交时，只需把修改对应的 Redo Log 写入磁盘（fsync），不必立刻刷脏页。即使数据库崩溃，重启后也能根据 Redo Log 重放操作，把已提交但未落盘的数据补全。
- Redo Log 是固定大小的循环文件组（如 ib_logfile0/ib_logfile1），写满后覆盖旧日志
- LSN（Log Sequence Number）全局递增，标识每条日志位置，也用于标记数据页的最新修改点
- innodb_flush_log_at_trx_commit=1 是默认且最安全的配置，保证每次 commit 都刷盘
MVCC + 行锁：支撑事务隔离性
InnoDB 默认使用可重复读（REPEATABLE READ）隔离级别。它不靠锁住整张表，而是结合隐藏字段（DB_TRX_ID、DB_ROLL_PTR）、Read View 和行级锁来实现非阻塞读与精确写保护。
- 每一行记录包含事务 ID 和指向 Undo Log 的指针，读操作根据当前事务的 Read View 判断哪些版本可见
- SELECT 不加锁（快照读），INSERT/UPDATE/DELETE 加行锁（当前读），避免幻读主要靠间隙锁（Gap Lock）和临键锁（Next-Key Lock）
- 唯一索引等值查询且记录存在时，只加记录锁；范围查询或无主键表容易升级为间隙锁，影响并发性能
事务状态与两阶段提交（2PC）
为了保证 Redo Log 和 Binlog 的一致性（尤其在主从复制场景），MySQL 在事务提交时采用逻辑上的两阶段提交：
- 第一阶段：InnoDB 将 Redo Log 写入并标记为 prepare 状态
- 第二阶段：MySQL Server 写入 Binlog，成功后再通知 InnoDB 提交事务（commit）
- 崩溃恢复时，MySQL 扫描 Redo Log 中 prepare 状态的事务，再检查 Binlog 是否完整，决定回滚或重做
