之前，我认为重做日志用于在发生崩溃时恢复数据库。 但是当我看到如下说明时，我觉得我错了：
崩溃恢复
崩溃后再次启动MySQL时发生的清理活动。对于InnoDB表，更改来自 使用重做日志中的数据重播不完整的事务。之前提交的更改 崩溃，但尚未写入数据文件，是从doublewrite缓冲区重建。当数据库是 正常关闭，这种类型的活动在关闭期间通过吹扫操作执行 在正常操作期间，提交的数据可以在更改缓冲区中存储一段时间 写入数据文件。在介绍数据文件保持最新之间总是需要权衡 正常操作期间的性能开销，以及缓冲数据，这可能导致关机和崩溃 恢复需要更长时间 另请参阅更改缓冲区，提交，崩溃，数据文件，双写缓冲区，InnoDB，清除，重做日志 它来自mysql refman-5.7-en.pdf。
如果是真的，我不知道重做日志的用途。因为，当崩溃发生时，mysql可以通过doublewrite缓冲区自行恢复。似乎重做日志毫无意义。也许我忽略了某个地方，但我不知道 我想知道它们之间的区别以及重做日志是否对mysql InnoDB很重要？
答案 0 :(得分：1)
重做日志似乎在较低的关键级别上起作用。我将mySQL用作桌面分析工具，因此我认为不需要生产数据库保护。关闭双重写入缓冲（innodb-doublewrite=0时，我发现查询性能得到了明显改善。没问题，已经超过一年了。重做日志是一个不同的故事。在禁用它的一周内，我最终需要重建数据库。
在8.0.21中，引入了切换重做日志（ALTER INSTANCE ENABLE|DISABLE REDO_LOG）的功能。 “为什么不尝试一下？”我想。关闭后，我发现加载速度提高了2％到5％。
这在加载大文件时会有所不同，尤其是如果使用Parallel Table Import Utility（在8.0.17中引入）。
不幸的是，我在写表时禁用了REDO LOG，并在工作站上出现了打ic，最后出现了此错误消息：
[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是严格且只读的。我不得不重建我的数据库（每次导入表时，无论如何我都会这样做），但是一些常数和历史记录的表我不得不手动恢复。
This is documented on the mySQL page Redo Log documentation page.重做日志上的注意事项会显示阴影的粗体警告警告。我应该听的。
我仍然禁用重做日志，但只能从运行并行导入实用程序的.js代码内部进行：
\sql
SET GLOBAL local_infile = 1;
ALTER INSTANCE DISABLE INNODB REDO_LOG;
我总是在代码中启用它。我保留了doublewrite缓冲区，因为任何呈现为部分的事务都可以通过重新加载表来轻松纠正。
答案 1 :(得分：-1)
这篇博文可能会回答你的问题：
点击here