你肯定在这里正确的轨道.
每当InnoDB执行必须提交的事务时,它都是作为两阶段提交完成的.事务首先写在这些日志中.然后,他们从那里承诺.
这在MySQL崩溃或服务器崩溃的情况下有很大帮助.
当你重新启动mysql时,ib_logfile0和ib_logfile1中的所有未提交的条目都会被重放,作为InnoDB崩溃恢复的一部分,使InnoDB处于和谐状态(这是ACID Compliance的一致和耐用部分)
如果删除ib_logfile0和ib_logfile1并启动mysql,那么这些文件包含的任何未提交的事务都将丢失.在崩溃恢复周期期间,如果缺少日志文件,则会根据innodb_log_file_size设置重新生成日志文件.
@karatedog InnoDB的MVCC部分发生在系统表空间内,更好地称为ibdata1.记录在事务开始之前出现的任何数据,以允许访问所需行的其他人在施加任何更新之前查看数据.这允许所谓的REPEATABLE-READ.这属于ACID合规性I,我的意思是隔离.关于事务隔离好,坏或丑的各种场景,我在DBA StackExchange中写了关于此的帖子.
至于MyISAM,crash recovery is not automatic. It crashes rather easily.这就是SQL命令REPAIR TABLE存在的原因.这也是为什么MySQL实用程序myisamchk具有-r选项为不在线的MyISAM表执行REPAIR TABLE的原因.
MariaDB and Aria一直试图将防撞安全存储引擎作为MyISAM的替代品.