MySQL事务日志

我正在从事一个项目，该项目要求我们在DBMS（MySQL）中使用“事务日志记录”。为了将事务用于另一个需求，我们已经切换到使用InnoDB。我试图理解什么是事务日志。我已经搜索了一天多了，包括阅读MySQL文档。也许我只是没有寻找正确的关键字，我不确定。或者，“事务日志”是不合适的术语

---

据我所知，数据库事务日志类似于日志文件系统，因为在将日志提交到文件系统之前，会对日志进行更改。据我所知，InnoDB引擎在将事务提交到磁盘之前，会将它们存储在某种日志中。这听起来准确吗？如果是，交易日志在哪里？是ib_logfile0和ib_logfile1吗

你在这条路上肯定走对了

每当InnoDB执行必须提交的事务时，它都作为两阶段提交完成。首先在这些日志中写入事务。然后，他们就从那里开始了

这在MySQL崩溃或服务器崩溃的情况下有很大帮助

当您重新启动mysql时，ib_logfile0和ib_logfile1中所有未提交的条目都会作为InnoDB崩溃恢复的一部分被重放，以使InnoDB处于和谐状态（这是系统的一致和持久部分）

如果删除ib_logfile0和ib_logfile1并启动mysql，则包含这些文件的所有未提交事务都将丢失。在崩溃恢复周期中，如果日志文件丢失，将根据设置重新生成日志文件

请看地图

@karatedog InnoDB的MVCC部分发生在系统表空间中，通常称为ibdata1。记录在事务开始之前显示的任何数据，以允许访问所需行的其他人在强制执行任何更新之前查看数据。这允许所谓的可重复读取。这属于酸性合规性，即隔离。我在dbastackexchange中就事务隔离好、坏或不好的各种场景写了相关文章

至于MyISAM。这就是SQL命令

修复表

存在的原因。这也是MySQL实用程序myisamchk

myisamchk

具有

-r

选项的原因，该选项可对不在线的MyISAM表执行

修复表

有人试图制作一个安全崩溃的存储引擎来替代MyISAM。
我知道这些日志文件用于崩溃恢复，但MVCC机制不负责在没有崩溃发生时正确执行“事务”吗？MyISAM有一定程度的崩溃恢复，但它根本没有事务。感谢您的详细及时回复。我对重放日志中的条目有点困惑。如果在事务的中间出现故障，在提交之前，我认为您不想重放条目，因为事务是全无的（您不希望提交事务的一部分）。或者您是说只有在有提交的情况下才会重放这些日志，但失败发生在事务提交到数据库之前，但在将其保存到日志文件之后？日志条目仅为更新或修改数据库的事务创建。一旦条目在数据库中成功提交，它们就会被删除。可以检测到日志条目已经提交，因此日志中记录的更新只执行一次！