MySQL のデータベースバッファプール (バッファプール) について理解します。

InnoDB ストレージエンジンを使用するテーブルの場合、メモリとディスク間のスワップインおよびスワップアウトの基本粒度として、ストレージスペースがページ単位で管理されます。ページをディスクからメモリにロードすると、ディスク I/O が実行されます。ディスク I/O のオーバーヘッドは全体のパフォーマンスに大きく影響しますが、対応するページをメモリから直接読み込めば、ディスク I/O によるパフォーマンスの低下が軽減され、効率が大幅に向上するのではないでしょうか。これを踏まえて、Buffer Pool (Buffer Pool) が登場したので、次は InnoDB の Buffer Pool について説明します。

バッファプール

バッファプールは非常に優れているので、すべてのデータをバッファプールに保存すればよいのではないかと考える人もいるかもしれません。いいえ、いいえ、バッファプールは、オペレーティングシステムによって割り当てられる連続したメモリです。メモリはディスクに比べて容量がはるかに小さく、高価です。それでは、オペレーティングシステムはバッファプールにどれだけのメモリを割り当てるのでしょうか?

デフォルトでは、バッファプールのサイズは 128MB です;

もちろん、マシンのメモリ容量が非常に大きい場合は、起動オプションパラメータを構成できます。構成ファイル innodb_buffer_pool_size の単位は bytes で、最小値は 5MB 未満にすることはできません。

バッファプールの内部構造

バッファプールは、オペレーティングシステムによって割り当てられた連続メモリを、デフォルトサイズ 16KB の複数のページ (バッファページ) に分割します [現時点では、ディスクページはバッファプールにキャッシュされます] ページをディスクからバッファプールにスワップするとき、その場所はどのように割り当てられますか?そのため、これらのバッファプール内のバッファページを識別するための制御情報が必要となり、この制御情報はコントロールブロックと呼ばれるメモリ領域に格納され、バッファページと１対１に対応している。制御ブロックのサイズも固定です。したがって、この連続したメモリ空間では、必然的にメモリの断片化が発生します。要約すると、バッファプールの内部構造は次のようになります。

バッファページ
制御ブロック: ページ番号、バッファプール内のバッファページのアドレス、リンクリストノード情報など
メモリの断片化 [メモリが適切に割り当てられている場合、メモリの断片化は不要です]

MySQL のデータベースバッファプール (バッファプール) について理解します。

バッファプールの管理

上記のリンク先リストノード情報は制御ブロックに記載されていますが、リンクリストノードは何に使用されるのでしょうか?これは、バッファープール内のページをより適切に管理するためです。制御ブロックとバッファページの間には 1 対 1 の対応があるため、リンクリストは制御ブロックをリンクするために使用されます。

1) フリーリンクリスト

すべてのフリーバッファページに対応するコントロールブロックをリンクして、リンクリストを形成します。

問題の解決策: ページをディスクからバッファープールにスワップするとき、バッファープール内のどのページが空いているかを識別するにはどうすればよいですか?フリーリンクリストでは、ディスクページがバッファプールにスワップされると、フリーリンクリストから直接フリーバッファページが取得され、ディスクページ内の対応する情報がバッファページに対応する制御ブロックに埋められます。そして、フリーリンクリストからコントロールブロックを削除するだけです。

2) リンクリストの更新

バッファプール内のバッファページのデータが変更され、ディスク上のデータと不整合が生じた場合、そのページはダーティページと呼ばれます。。すべてのダーティページに対応する制御ブロックをリンクして更新リンクリストを形成し、このリンクリストに基づいて将来のある時点で対応するキャッシュページのデータをディスクにリフレッシュします。

3) LRU リンクリスト

バッファプールのサイズには制限があり、キャッシュされたページがバッファプールのサイズを超える場合、つまり、空きバッファページがありません。追加される新しいページです。バッファプールに入るとき、LRU 戦略が採用され、バッファプールから古いバッファページが削除されてから、新しいページが追加されます。 LRU リンクリストは内容が多いので、次回は別途紹介します。

LRUリンクリストに含まれる「理念」

まずは先読みの仕組みについて触れておきます

I/Oの最適化の仕組みその名の通り、これらのページはバッファプールにロードされ、すぐに必要になることが予想されます。これらのリクエストでは、範囲内のすべてのページが導入されます。これは、いわゆる ローカリティ原則 . 目的は、ディスク I/O を削減することです。

先読みメカニズムを理解する前に、InnoDB の論理ストレージユニット (テーブルスペース → セグメント → エクステント → ページ) を確認してみましょう。後で使用する領域について具体的に説明します。領域は、物理的な場所で連続した 64 ページ です。つまり、領域のサイズは 1MB です。

MySQL のデータベースバッファプール (バッファプール) について理解します。

先読みメカニズムは、次の 2 つのタイプに細分できます。

線形先読み: バッファプール内で順次アクセスされるページに基づいて、どのページがすぐに必要になるかを予測する手法。 innodb_read_ahead_threshold パラメータを設定すると、連続してアクセスされる特定の領域のページがこのパラメータの値を超えると、非同期読み取りリクエストがトリガーされ、次の領域のすべてのページがバッファプールに読み込まれます。
ランダム先読み: ページが読み取られる順序に関係なく、バッファプール内にすでにあるページに基づいて、ページがいつ必要になるかを予測できます。同じエクステントの連続した 13 ページがバッファプール内で見つかった場合、InnoDB はエクステントの残りのページをプリフェッチするリクエストを非同期的に発行します。ランダム読み取りは、変数 innodb_random_read_ahead を構成することで制御されます。

LRU アルゴリズムを使用して、最も最近使用されていないバッファページを管理し、対応するリンクリストを形成して簡単に削除します。

ページがアクセスされると (つまり、最新のアクセスが)

ページがバッファープール内にあると、対応する制御ブロックがリンクされた LRU の先頭に移動されます。 list

ページはバッファプールにありません。バッファプールでは、最後にある最も最近使用されていないページが削除され、そのページがディスクからロードされ、LRU リンクリストの先頭に配置されます
では、なぜ InnoDB はこのような直感的な LRU アルゴリズムを使用しないのでしょうか?理由は次のとおりです。

先読み失敗
バッファプールに先読みされたページは、LRU の先頭に配置されます。リンクされたリストですが、その多くはページが読み取れない可能性があります。
バッファプールの汚染
低頻度のページをバッファプールに多数読み込むと、高頻度のページがバッファから削除されます。プールから削除されます。。たとえば、
full table scan

上記の欠点に基づいて、特定の最適化された方法では、従来の LRU リンクリストをホットデータエリア [若いエリア] とコールドデータエリア [古いエリア] の 2 つの部分に分割します。

ホットデータ領域 [若い領域]

: 使用頻度の高いバッファページ

コールドデータ領域 [古い領域] : 使用頻度の低い領域
構造図は次のとおりです。

図に示すように、ホットデータ領域とコールドデータ領域はそれぞれ異なる割合を占めています。

innodb_old_blocks_pct オプションは、コールドデータ領域の割合を制御します。

#改良された LRU は、先読み障害の問題をどのようにより適切に解決できるでしょうか?

MySQL のデータベースバッファプール (バッファプール) について理解します。

ページが初めてバッファプールにロードされると、コールドデータ領域の末尾にある制御ブロックが最初に削除されます (つまり、対応するページが削除されます)。とすると、新しいページに対応するコントロールブロックが削除され、コールドデータ領域の先頭にブロックが配置されます。

ページがその後アクセスされない場合、そのページはコールドデータ領域から徐々に削除されますが、通常、ホットデータ領域内の頻繁にアクセスされるバッファページには影響しません。

改良された LRU は、バッファプール汚染の問題をどのように解決できるでしょうか?
結論を先に話します。この問題は十分に最適化されていません。理由は次のとおりです [テーブル全体のスキャンを例に挙げます]:

A初めてアクセスしたページもコールドデータ領域の先頭に配置されますが、その後のアクセスではホットデータ領域の先頭に配置され、アクセス頻度の高いページも排除されます。

では、バッファプール汚染の問題を解決するにはどうすればよいでしょうか?

バッファプールでは、コールドデータ領域の時間ウィンドウメカニズムが導入されています。つまり、ページへのその後のアクセスとページへの最初のアクセスの間の時間間隔が、指定されたウィンドウ値より大きい場合にのみ、コールドデータ領域からページが削除され、ホットデータ領域の先頭に移動します。ウィンドウ値が指定値より小さい場合、移動操作は実行されません。

同様に、ウィンドウ値は

innodb_old_blocks_time

パラメーター [単位 ms] で設定できます。デフォルトは 1000 ミリ秒で、1 秒を指定すると、テーブル全体のスキャンなどのほとんどの操作が除外されます。たとえば、テーブル全体のスキャン中、ページへの複数のアクセス間の時間間隔は 1 秒を超えることはありません。

バッファプール VS クエリキャッシュ
バッファプールとクエリキャッシュは同じものですか? →Not

バッファプールは頻繁に使用されるデータを保存しようとします。MySQL がページ読み取り操作を実行するとき、最初にページがバッファプール内にあるかどうかを判断します。存在する場合は、直接読み取られます。ページが存在しない場合、ページはメモリまたはディスクを介してバッファプールに保存されてから読み取られます。

クエリキャッシュとは、クエリ結果を事前にキャッシュし、次回実行することなく結果を直接取得できるようにすることです。 MySQL のクエリキャッシュはクエリプランをキャッシュするのではなく、クエリの対応する結果をキャッシュすることに注意してください。ヒット条件が厳しく、データテーブルが変更されるとクエリキャッシュが無効になるため、ヒット率が低くなります。