InnoDB ストレージ エンジンを使用するテーブルの場合、メモリとディスク間のスワップインおよびスワップアウトの基本粒度として、ストレージ スペースがページ単位で管理されます。ページをディスクからメモリにロードすると、ディスク I/O が実行されます。ディスク I/O のオーバーヘッドは全体のパフォーマンスに大きく影響しますが、対応するページをメモリから直接読み込めば、ディスク I/O によるパフォーマンスの低下が軽減され、効率が大幅に向上するのではないでしょうか。これを踏まえて、Buffer Pool (
Buffer Pool
) が登場したので、次は InnoDB の Buffer Pool について説明します。
バッファ プールは非常に優れているので、すべてのデータをバッファ プールに保存すればよいのではないかと考える人もいるかもしれません。いいえ、いいえ、バッファ プールは、オペレーティング システムによって割り当てられる連続したメモリです。メモリはディスクに比べて容量がはるかに小さく、高価です。それでは、オペレーティング システムはバッファ プールにどれだけのメモリを割り当てるのでしょうか?
もちろん、マシンのメモリ容量が非常に大きい場合は、起動オプション パラメータを構成できます。構成ファイル innodb_buffer_pool_size
の単位は bytes で、最小値は 5MB 未満にすることはできません。
バッファ プールは、オペレーティング システムによって割り当てられた連続メモリを、デフォルト サイズ 16KB の複数のページ (バッファ ページ) に分割します [現時点では、ディスク ページはバッファ プールにキャッシュされます] ページをディスクからバッファ プールにスワップするとき、その場所はどのように割り当てられますか?そのため、これらのバッファプール内のバッファページを識別するための制御情報が必要となり、この制御情報はコントロールブロックと呼ばれるメモリ領域に格納され、バッファページと1対1に対応している。制御ブロックのサイズも固定です。したがって、この連続したメモリ空間では、必然的にメモリの断片化が発生します。要約すると、バッファ プールの内部構造は次のようになります。
上記のリンク先リストノード情報は制御ブロックに記載されていますが、リンクリストノードは何に使用されるのでしょうか?これは、バッファー プール内のページをより適切に管理するためです。制御ブロックとバッファ ページの間には 1 対 1 の対応があるため、リンク リストは制御ブロックをリンクするために使用されます。
すべてのフリー バッファ ページに対応するコントロール ブロックをリンクして、リンク リストを形成します。
問題の解決策: ページをディスクからバッファー プールにスワップするとき、バッファー プール内のどのページが空いているかを識別するにはどうすればよいですか?フリー リンク リストでは、ディスク ページがバッファ プールにスワップされると、フリー リンク リストから直接フリー バッファ ページが取得され、ディスク ページ内の対応する情報がバッファ ページに対応する制御ブロックに埋められます。そして、フリーリンクリストからコントロールブロックを削除するだけです。
バッファ プール内のバッファ ページのデータが変更され、ディスク上のデータと不整合が生じた場合、そのページはダーティ ページと呼ばれます。 。すべてのダーティ ページに対応する制御ブロックをリンクして更新リンク リストを形成し、このリンク リストに基づいて将来のある時点で対応するキャッシュ ページのデータをディスクにリフレッシュします。
バッファ プールのサイズには制限があり、キャッシュされたページがバッファ プールのサイズを超える場合、つまり、空きバッファ ページがありません。追加される新しいページです。バッファ プールに入るとき、LRU 戦略が採用され、バッファ プールから古いバッファ ページが削除されてから、新しいページが追加されます。 LRU リンクリストは内容が多いので、次回は別途紹介します。
I/Oの最適化の仕組みその名の通り、これらのページはバッファ プールにロードされ、すぐに必要になることが予想されます。これらのリクエストでは、範囲内のすべてのページが導入されます。これは、いわゆる ローカリティ原則
. 目的は、ディスク I/O を削減することです。
先読みメカニズムを理解する前に、InnoDB の論理ストレージ ユニット (テーブルスペース → セグメント → エクステント → ページ) を確認してみましょう。後で使用する領域について具体的に説明します。領域は、物理的な場所で連続した 64 ページ
です。つまり、領域のサイズは 1MB です。
先読みメカニズムは、次の 2 つのタイプに細分できます。
ページがアクセスされると (つまり、最新のアクセスが)
ページがバッファー プール内にあると、対応する制御ブロックがリンクされた LRU の先頭に移動されます。 listバッファ プールに先読みされたページは、LRU の先頭に配置されます。リンクされたリストですが、その多くはページが読み取れない可能性があります。
低頻度のページをバッファ プールに多数読み込むと、高頻度のページがバッファから削除されます。プールから削除されます。 。たとえば、
full table scan
: 使用頻度の高いバッファページ
innodb_old_blocks_pct オプションは、コールド データ領域の 割合を制御します。
#改良された LRU は、先読み障害の問題をどのようにより適切に解決できるでしょうか?
ページがその後アクセスされない場合、そのページはコールド データ領域から徐々に削除されますが、通常、ホット データ領域内の頻繁にアクセスされるバッファ ページには影響しません。
A初めてアクセスしたページもコールドデータ領域の先頭に配置されますが、その後のアクセスではホットデータ領域の先頭に配置され、アクセス頻度の高いページも排除されます。
では、バッファプール汚染の問題を解決するにはどうすればよいでしょうか?
innodb_old_blocks_time
パラメーター [単位 ms] で設定できます。デフォルトは 1000 ミリ秒で、1 秒を指定すると、テーブル全体のスキャンなどのほとんどの操作が除外されます。たとえば、テーブル全体のスキャン中、ページへの複数のアクセス間の時間間隔は 1 秒を超えることはありません。
バッファ プールとクエリ キャッシュは同じものですか? →Notクエリ キャッシュとは、クエリ結果を事前にキャッシュし、次回実行することなく結果を直接取得できるようにすることです。 MySQL のクエリ キャッシュはクエリ プランをキャッシュするのではなく、クエリの対応する結果をキャッシュすることに注意してください。ヒット条件が厳しく、データテーブルが変更されるとクエリキャッシュが無効になるため、ヒット率が低くなります。
以上がMySQL のデータベース バッファ プール (バッファ プール) について理解します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。