MySQL事务提交需确保redo log持久化（默认参数值1时fsync落盘）、undo log标记已提交但延迟清理、行级锁原子释放、并协同binlog通过两阶段提交保证主从一致。
MySQL 事务提交不是简单的一条“COMMIT”命令就完事，它背后涉及日志写入、缓存刷新、锁释放等多个关键环节，尤其在 InnoDB 存储引擎下，整个流程严格遵循 WAL（Write-Ahead Logging） 原则——先写日志，再改数据。
redo log 刷盘是事务提交的“法律依据”
事务提交时，InnoDB 必须确保对应的 redo log 已持久化到磁盘（或至少到达操作系统页缓存），这是崩溃恢复的唯一凭证。是否真正落盘，取决于 innodb_flush_log_at_trx_commit 参数设置：
- 值为 1（默认）：每次 COMMIT 都调用 fsync 将 redo log 写入磁盘，最安全，性能略低；
- 值为 0：每秒刷一次 log buffer，崩溃可能丢失最多 1 秒事务；
- 值为 2：每次 COMMIT 写入 OS 缓存，由系统异步刷盘，崩溃可能丢失已提交事务（若 OS 挂了）。
面试中强调：只要该参数为 1，即使 MySQL 进程崩溃，重启后也能通过 redo log 恢复已提交事务——这就是 ACID 中 Durability 的底层保障。
undo log 和行记录版本链同步更新
事务提交不等于立即清理 undo 日志。InnoDB 会把该事务的 undo log 标记为“已提交”，但实际清理要等 purge 线程 判断：没有其他活跃事务需要通过这条 undo 记录做 MVCC 读取（即没有更老的 read view）时，才异步回收。
同时，事务修改的聚簇索引记录的 trx_id 字段会被更新为当前事务 ID，并将 roll_ptr 指向其 undo log 中的上一版本——这构成了 MVCC 的版本链基础。提交只是“封存”这个版本，而非删除旧版本。
锁释放与事务状态切换
事务提交瞬间，InnoDB 会批量释放该事务持有的所有行级锁（record lock、gap lock、next-key lock）和表级意向锁（IX/IS）。注意：
- 锁释放是原子操作，不会出现“部分释放”；
- 如果事务中有 SELECT ... FOR UPDATE 或 INSERT/UPDATE/DELETE，对应锁会在 COMMIT 后立刻解除，其他事务可立即获取；
- 但自增锁（auto-inc lock）在语句执行完就释放，不等到 COMMIT。
此时事务状态从 ACTIVE 变为 COMMITTED，其事务 ID 不再参与新事务的 read view 构建。
binlog 写入与主从一致性协同（若开启）
当 MySQL 同时启用 binlog（如用于主从复制），事务提交还涉及 两阶段提交（2PC） 协调机制：
- 第一阶段：InnoDB prepare（写入 redo log 并标记为 prepared）；
- 第二阶段：Server 层写入 binlog；
- 第三阶段：InnoDB commit（完成 redo log 提交并释放锁）。
这个顺序防止了主库崩溃后出现“binlog 有记录但引擎层未提交”的数据不一致。若 crash 发生在 prepare 后、binlog 前，恢复时回滚；若发生在 binlog 后、commit 前，恢复时重做 commit —— 保证引擎层与 binlog 最终一致。
理解事务提交，本质是理解 InnoDB 如何用 redo、undo、锁、binlog 四者协作，在性能与可靠性之间取得平衡。面试答到 WAL、2PC、prepare-commit 分界点、以及 innodb_flush_log_at_trx_commit 的影响，基本就到位了。
