`innodb_max_dirty_pages_pct`の正確な意味は何ですか、それはREDOログとどのように関連していますか？
innodb_max_dirty_pages_pctパラメータと、そのREDOログとの関係に戸惑っています。
定義自体は簡単です。
InnoDBは、ダーティページの割合がこの値を超えないように、バッファープールからデータをフラッシュしようとします。
しかし、私を混乱させるのは、REDOログとの関係です。
「データのフラッシュ」は次のことを意味しますか？
- ダーティページをログバッファからREDOログにコピーする、または
- rEDOログからバッファプールファイルへ？
ケース1がどのように発生するか想像できません。 innodb_flush_log_at_trx_commit = 0を備えたシステムでも、ログは1秒に1回フラッシュされるので、バッファープールの90％を1秒でどのように変更できますか？
ケースが代わりに2である場合（この解釈は（チェックポイントの経過時間>合計ログサイズ* pct）となると思います）、このような多数のダーティページはREDOログに収まりません。
私は何を誤解していますか？
あなたは言う：
ログは毎秒1回フラッシュされるので、バッファープールの90％を1秒でどのように変更できますか？ [...]このような多数のダーティページがREDOログに収まらない
ログバッファとバッファプールは同じ意味であると考えているようです。それは真実ではありません。
バッファプールからのダーティページのフラッシュとREDOログの間には関係がありません。ログバッファーとバッファープールは異なる目的で使用され、個別に管理されます。
バッファープールは、InnoDB テーブルとインデックスデータをキャッシュするであるメインメモリ内の領域です。
そして
ログバッファは、データを保持するメモリ領域ですログファイルに書き込まれるディスク
（エンファシス鉱山。）
ダーティデータまたはインデックスページがフラッシュされるときまでに、対応するログレコードは既に書き出されています-これが先読みロギングの性質です。ダーティページをバッファプールからフラッシュすると、これらのページが適切なibdata*および/または.ibdファイル。
RolandoMySQLDBAによる編集
Percona CTO Vadim TkachenkoによるInnoDBの視覚表現の追加
最初に理解しておくべきことは、REDOログバッファーとログファイルには、バッファープールとデータファイルと同じタイプのアイテムが含まれていないことです（ here を参照）。 REDOログからバッファープールへ、またはバッファープールからREDOログへコピーされる項目はありません。したがって、両者の関係についての両方の見方は正しくありません。
「データのフラッシュ」とは、バッファープールからデータファイルにページを書き込むことを意味します（ ここ を参照）。
おもう innodb_max_dirty_pages_pct対応するログレコードがすでにディスクに書き込まれる前にダーティページをフラッシュできないため、REDOログとの関係がまだあります（ドキュメントで確認を見つけることができませんが、そうでない場合、データベースの復元手順に一貫性のないセットがあるためですログデータレコード）。
したがって、innodb_max_dirty_pages_pctに達し、バックグラウンドプロセスがディスクに書き込むことができるページを見つけようとしますが、対応するREDOログレコードがディスク上のバッファーから書き込まれないため、REDOログのフラッシュがトリガーされ、フォアグラウンドの一時的なスローダウンが発生する可能性があります。操作。 （しかし、十分な大きさのバッファー・プールではほとんど起こりません。）