以前は、クラッシュが発生したときにデータベースを回復するために REDO ログが使用されると考えていました。しかし、次のような注記を見て、私は間違っていると感じました。
クラッシュリカバリ
クラッシュ後に MySQL が再起動されたときに発生するクリーンアップ アクティビティ。InnoDB テーブルの場合、不完全なトランザクションからの変更は、REDO ログのデータを使用して再生されます。クラッシュの前にコミットされたが、まだデータ ファイルに書き込まれていない変更は、二重書き込みバッファーから再構築されます。データベースが正常にシャットダウンされると、パージ操作によってシャットダウン中にこのタイプのアクティビティが実行されます。
通常の操作中、コミットされたデータは、データ ファイルに書き込まれる前に一定期間、変更バッファに格納できます。データ ファイルを最新の状態に保つこと (通常の操作中にパフォーマンス オーバーヘッドが発生する) と、データをバッファリングすること (シャットダウンやクラッシュ リカバリに時間がかかる可能性がある) との間には、常にトレードオフがあります。変更バッファ、コミット、クラッシュ、データ ファイル、ダブルライト バッファ、InnoDB、パージ、やり直しログも参照してください。
mysql refman-5.7-en.pdf からのものです。
もし本当なら、REDOログが何の役に立つのかわかりません。クラッシュが発生した場合、mysql は doublewrite バッファを介して自身を回復できるためです。REDOログは意味がないようです。どこかを無視しているのかもしれませんが、わかりません。
それらの違いと、mysql InnoDB にとって再実行ログが重要かどうかを知りたいですか?