MySQL宕机后已提交事务数据不丢失，前提是innodb_flush_log_at_trx_commit=1且磁盘write cache禁用；因InnoDB采用WAL机制，先将物理页修改写入redo log并刷盘，重启后通过重放redo log恢复脏页。
不会丢失，前提是事务已提交且 innodb_flush_log_at_trx_commit 设置为 1（默认值）。
UPDATE 执行后宕机，为什么数据还能恢复？
因为 InnoDB 在更新 Buffer Pool 中的数据页时，同步把变更写入了 redo log。这个日志记录的是「物理页修改」——比如「在表空间 3 的第 1024 页、偏移量 256 处，将 4 字节的整数从 0 改为 1」。只要这条 redo log 成功刷盘（fsync），即使后续 MySQL 突然宕机、Buffer Pool 中的脏页还没写回磁盘，重启后也会通过重放 redo log 把页恢复到一致状态。
关键点在于：不是靠「数据页落盘」保证不丢，而是靠「日志先落盘」。这就是 WAL（Write-Ahead Logging）的核心逻辑。
-
redo log是循环写入的固定大小文件（如ib_logfile0和ib_logfile1），不是无限增长 - 它只由 InnoDB 引擎生成和解析，Server 层不可见
- 它不记录 SQL 语句本身，也不记录 WHERE 条件，只记「改了哪个页、怎么改的」
为什么有时候看起来像丢了数据？
常见误判场景有两类：
- 事务未提交就宕机：
UPDATE在执行器层完成、但还没走到COMMIT，此时redo log处于prepare状态，MySQL 重启后会回滚该事务 -
innodb_flush_log_at_trx_commit = 0或2：前者日志仅写入 OS 缓冲区（可能未fsync），后者仅fsync到磁盘但不保证立即落盘；这两种配置下，宕机前最后一秒的提交仍可能丢失 - 用了 MyISAM 引擎：它没有
redo log，宕机即丢已提交数据 —— 这不是 bug，是引擎设计限制
两阶段提交（2PC）到底在协调什么？
MySQL 同时依赖 redo log（引擎层）和 binlog（Server 层），而两者落盘时机不同。2PC 就是为了让它们状态一致：
- 第一阶段（prepare）：InnoDB 将
redo log写入并标记为prepare，返回准备就绪 - 第二阶段（commit）：MySQL Server 写
binlog并fsync；成功后通知 InnoDB 提交，redo log状态改为commit
如果在 prepare 后、binlog 写入前宕机，重启后发现 redo log 是 prepare 状态但无对应 binlog，则回滚；反之，如果 binlog 已写但 redo log 未 commit，就补 commit。这个机制确保主从复制和崩溃恢复不矛盾。
真正容易被忽略的是：2PC 不是为性能设计的，它是为「一致性兜底」服务的。一旦你关掉 binlog（比如纯本地开发库），InnoDB 就退化为单阶段提交，redo log 自己管好自己的 commit 就行。
