以前，我认为重做日志是用来恢复发生崩溃时的数据库。但是当我看到下面的注释时，我觉得我错了:
崩溃恢复MySQL在崩溃后重新启动时发生的清理活动。对于InnoDB表，从使用重做日志中的数据重放未完成的事务。之前提交的更改崩溃，但尚未写入数据文件，从doublewrite缓冲区重建。当数据库为正常关闭时，这种类型的活动在关闭期间由清除操作执行。
在正常操作期间，提交的数据可以在更改缓冲区中存储一段时间，然后才被删除写入数据文件。在保持数据文件最新之间总是有一个权衡，这就引入了正常操作期间的性能开销，以及对数据的缓冲，可能导致关机和崩溃恢复需要更长时间。参见更改缓冲区，提交，崩溃，数据文件，双写缓冲区，InnoDB，清除，重做日志。
它来自mysql refman-5.7-en.pdf。
如果是真的，我不知道redo log有什么用。因为，当发生崩溃时，mysql可以通过doublewrite buffer恢复自己。似乎重做日志没有意义。也许我忽略了什么，但我不知道。
我想知道他们之间的区别，是否重做日志是重要的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页面Redo Log文档页面上有记录。重做日志上的警告得到一个黑体阴影警告标注。我应该听的。
我仍然禁用重做日志，但只能从运行并行导入实用程序的.js代码内部:
sql
SET GLOBAL local_infile = 1;
ALTER INSTANCE DISABLE INNODB REDO_LOG;
在代码中我总是让它处于启用状态。我将doublewrite缓冲区保留为关闭状态，因为我可以通过重新加载表轻松地更正任何呈现部分的事务。
也许这篇博文会回答你的问题:
点击这里