以前，我认为重做日志是用来在发生崩溃时恢复数据库的。但是当我看到下面的注释时，我觉得我错了：
崩溃恢复
崩溃后再次启动 MySQL 时发生的清理活动。对于 InnoDB 表，使用重做日志中的数据重播来自不完整事务的更改。崩溃前提交但尚未写入数据文件的更改将从双写缓冲区中重建。当数据库正常关闭时，这种类型的活动在关闭期间由清除操作执行。
在正常操作期间，提交的数据可以在更改缓冲区中存储一段时间，然后再写入数据文件。在保持数据文件最新（这会在正常操作期间引入性能开销）和缓冲数据（这会使关机和崩溃恢复需要更长的时间）之间总是需要权衡取舍。另见更改缓冲区、提交、崩溃、数据文件、双写缓冲区、InnoDB、清除、重做日志。
它来自 mysql refman-5.7-en.pdf。
如果是真的，不知道redo log有什么用。因为，当崩溃发生时，mysql 可以通过双写缓冲区自行恢复。似乎重做日志没有意义。也许我忽略了某个地方，但我不知道。
我想知道它们之间的区别以及重做日志对 mysql InnoDB 是否重要？
重做日志似乎在较低的更关键级别上运行。我使用 mySQL 作为桌面分析工具，所以我认为我不需要生产数据库保护。当双写缓冲关闭时，我发现查询性能显着提高（innodb-doublewrite=0）。没问题，一年多了。重做日志是一个不同的故事。在禁用它的一周内，我最终需要重建我的数据库。
在 8.0.21 中，ALTER INSTANCE ENABLE|DISABLE REDO_LOG引入了切换重做日志 ( ) 的功能。“为什么不试试呢？” 我想。关闭后，我看到加载速度提高了 2-5%。
这在加载大文件时会有所不同，尤其是在使用并行表导入实用程序（在 8.0.17 中引入）时。
不幸的是，我禁用了 REDO LOG，并在我写表时在我的工作站上遇到了问题，最后得到了这个错误消息：
[ERROR] [MY-013578] [InnoDB] Server was killed when Innodb Redo logging was disabled. Data files could be corrupt. You can try to restart the database with innodb_force_recovery=6
我必须初始化一个新实例，因为在我收到此错误后，没有一个表可以让我写任何东西。
Force_recovery=6是严格且只读的。我不得不重建我的数据库（大多数情况下我每次导入表时都会这样做），但是我必须手动恢复一些常量和历史表。
这记录在 mySQL 页面重做日志文档页面上。 重做日志上的警告得到一个阴影粗体警告标注。我应该听的。
我仍然禁用重做日志，但只能从运行并行导入实用程序的 .js 代码内部：
\sql
SET GLOBAL local_infile = 1;
ALTER INSTANCE DISABLE INNODB REDO_LOG;
我总是在代码中启用它。我将双写缓冲区关闭，因为任何呈现部分的事务我都可以通过重新加载表轻松纠正。
也许这篇博文会回答你的问题：
点击这里