InnoDB崩溃后事务未丢失，因其通过ib_logfile（redo log）前滚重做已提交但未刷盘的修改；redo log不保存未提交事务状态，仅记录物理页变更，配合undo log回滚未提交事务。
崩溃后为什么事务没丢？InnoDB靠ib_logfile重做已提交但未刷盘的修改
MySQL重启时，InnoDB不是“从头读数据文件”，而是先检查ib_logfile0和ib_logfile1（即redo log），把其中已提交但还没写进ibdata1或表空间的数据页变更，重新应用一遍——这个过程叫“前滚”（redo）。它不关心SQL逻辑，只按物理页偏移+字节修改来重放。
-
innodb_flush_log_at_trx_commit=1（默认）：每次COMMIT都强制刷日志到磁盘，崩溃后能100%恢复所有已提交事务 -
=0或=2：日志只每秒刷一次，崩溃可能丢失最近1秒内已提交的事务 - redo log里**不存未提交事务的最终状态**，只记“某页第X字节改成Y”。所以它不能用来恢复未提交事务，反而会配合undo log一起回滚它们
误删数据后怎么找回？mysqlbinlog才是关键，ib_logfile帮不上忙
redo log是循环覆盖的物理日志，生命周期短、不归档、不记录SQL语义；而真正支持“时间点恢复”的是二进制日志（binlog）。只要log_bin=ON且格式为ROW或MIXED，你就能用mysqlbinlog反解析出被删的行。
- 先定位误操作位置：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A 10 "DELETE FROM users" - 找到
# at 123456这样的position，或更稳妥的GTID段（如8a1f2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c:12345） - 恢复时用
--start-position跳过坏操作，或--exclude-gtids直接剔除整个事务 - 切勿直接
mysqlbinlog xxx | mysql——里面可能含DROP TABLE，会二次破坏结构
为什么不能手动删ib_logfile*？删了就启动不了
InnoDB启动时会校验ibdata1头部记录的日志序列号（LSN）是否与ib_logfile当前的LSN连续。手动删除ib_logfile0和ib_logfile1，会导致启动报错：InnoDB: The log sequence number in ibdata files does not match。
- 真要调大
innodb_log_file_size：必须停库 → 删除旧ib_logfile*→ 修改配置 → 启动（InnoDB会自动重建） -
ib_logfile大小影响性能与恢复时间：太小→频繁checkpoint，写入抖动；太大→崩溃后前滚耗时久（可能几分钟） - 别指望靠它做备份或归档——它不是设计来给人读的，也没提供导出接口
ROLLBACK只能撤回未提交的操作，对已提交的误删完全无效
事务回滚（ROLLBACK）只作用于当前连接中BEGIN之后、尚未COMMIT的语句。一旦执行了COMMIT，数据就进了ibdata1或独立表空间，ROLLBACK再无能力撤销。
- 常见误解：“刚删完表，赶紧
ROLLBACK！”——如果已经COMMIT或自动提交开启（autocommit=1），这步毫无意义 - MyISAM表不支持事务，
ROLLBACK执行成功但实际什么都不会发生 - 想防这类问题，得靠外部机制：定期
mysqldump+ 开启binlog+ 设置read_only=ON限制高危操作权限
真正难的是判断“哪段binlog该跳过、哪段该重放”，尤其当业务混着DDL和DML、又跨多个binlog文件时，position和GTID的对应关系容易看错——这时候多花两分钟确认SHOW BINLOG EVENTS IN 'mysql-bin.000012' FROM 123456 LIMIT 20，比盲目恢复强得多。
