mysql事务不丢数据的关键是innodb_flush_log_at_trx_commit=1和sync_binlog=1共同生效，确保2pc中prepare阶段redo log强制fsync落盘、commit前binlog完整写入，配合xid交叉校验实现崩溃后精准恢复。
MySQL事务不丢数据，靠的不是“两阶段提交”本身，而是innodb_flush_log_at_trx_commit=1和sync_binlog=1这两个参数共同生效后，让2PC流程强制落盘的结果。
prepare阶段必须真正写盘，否则崩溃即丢失
很多人误以为只要开了binlog、用了事务，就天然不丢数据。实际不是：如果innodb_flush_log_at_trx_commit设为0或2，prepare阶段的redo log只写进buffer或文件系统缓存，没调用fsync落盘。此时若MySQL进程崩溃或机器断电，prepare记录彻底消失——重启后MySQL根本看不到这个事务，自然不会去binlog里查XID，也就无法补commit，该事务直接人间蒸发。
所以关键点是：
-
innodb_flush_log_at_trx_commit=1是硬性前提，它确保每次prepare都触发fsync - prepare状态本身不释放锁、不更新MVCC可见性，但已占用undo资源；它唯一作用就是“留个记号”，等binlog来认领
- 没有这个落盘的prepare，后续任何binlog写入都失去锚点，2PC形同虚设
commit阶段依赖binlog成功写盘，顺序不可颠倒
Server层只有在收到InnoDB返回prepare成功后，才开始把事务的binlog event写入文件缓冲区，再调用fsync刷盘。这一步的sync_binlog=1同样不能妥协。
常见错误场景：
- 磁盘满导致
write成功但fsync失败 → 整个事务回滚，redo log中prepare记录被清理 - binlog写成功，但MySQL在发commit指令前crash → 重启时扫描binlog末尾XID，在redo log中找到对应prepared事务，补上commit标记
- 若把顺序反过来（先commit redo log再写binlog），一旦binlog写失败，事务已在引擎层提交，无法回滚，主从必然不一致
崩溃恢复时靠XID交叉校验，不是靠猜
MySQL启动时不做“事务该不该恢复”的主观判断，而是机械执行三步：
- 扫描redo log，找出所有
TRX_STATE_PREPARED事务，提取它们的XID - 读取binlog文件末尾（或最后一个完整event）的XID
- 如果某个prepared事务的XID在binlog中存在 → 补
commit；否则→ 回滚
这意味着：binlog文件必须完整、可解析，且不能被截断或损坏。使用mysqlbinlog --base64-output=DECODE-ROWS -v可人工验证XID是否存在，但生产环境更依赖sync_binlog=1保障binlog物理完整性。
真正容易被忽略的是：innodb_support_xa在5.7.9+虽默认ON，但如果被显式设为OFF，MySQL会跳过prepare阶段，退化为单阶段提交——此时即使两个sync参数都开着，2PC逻辑也不触发。线上巡检必须确认该值为ON，而不是只盯show variables like '%sync%'。
