我正在开发一个项目，我们需要在我们的 DBMS（MySQL）中使用“事务日志”。我们已经切换到使用 InnoDB 以便将事务用于另一个需求。我试图了解什么是事务日志。我已经搜索了一天多，包括阅读 MySQL 文档。也许我只是没有搜索正确的关键字，我不确定。或者“事务日志”可能是不恰当的术语。
据我了解，数据库事务日志类似于日志文件系统，因为在将日志提交到文件系统之前对日志进行了更改。根据我的阅读，听起来 InnoDB 引擎在将事务提交到磁盘之前将它们存储在某种日志中。这听起来准确吗？如果是这样，交易日志在哪里？是 ib_logfile0 和 ib_logfile1 吗？
你在这里绝对是在正确的轨道上。
每当 InnoDB 执行必须提交的事务时，它都是作为两阶段提交完成的。事务首先写入这些日志。然后，他们从那里承诺。
这在 MySQL 崩溃或服务器崩溃的情况下有很大帮助。
当您重新启动 mysql 时，ib_logfile0 和 ib_logfile1 中的所有未提交条目将作为 InnoDB 崩溃恢复的一部分重播，以使 InnoDB 进入和谐状态（这是ACID Compliance的 Consistent and Durable 部分）
如果删除 ib_logfile0 和 ib_logfile1 并启动 mysql，这些文件包含的任何未提交的事务都将丢失。在崩溃恢复周期中，如果日志文件丢失，它们会根据innodb_log_file_size设置重新生成。
有关 InnoDB 的详细说明，请参阅MySQL 文档。
@karatedog InnoDB 的 MVCC 部分发生在系统表空间中，也就是众所周知的 ibdata1。记录在事务开始之前出现的任何数据，以允许访问所需行的其他人在强制执行任何更新之前查看数据。这允许所谓的可重复阅读。这属于 ACID 合规性 I，我的意思是隔离。我在 DBA StackExchange 中写了关于事务隔离是好、坏或丑的各种场景的帖子。
至于 MyISAM，崩溃恢复不是自动的。它很容易崩溃。这就是 SQL 命令REPAIR TABLE存在的原因。这也是为什么 MySQL 实用程序myisamchk可以-r选择对REPAIR TABLE不在线的 MyISAM 表执行的原因。
MariaDB 和 Aria一直在尝试制作一个崩溃安全的存储引擎来替代 MyISAM。