MySQLバッファプールバッファプールの詳細説明

アプリケーションシステムでは、データアクセスを高速化するために、頻度の高いデータを「キャッシュ」 (Redis、MongoDB)に入れてデータベースへの負担を軽減します。

オペレーティングシステムでは、ディスク IO を削減するために、「バッファプール」メカニズムが導入されています。

ストレージシステムとして、MySQL にはパフォーマンスを向上させ、ディスク IO を削減するためのバッファプールメカニズムもあります。構造図は次のとおりです。

「上記の構造図は、バッファプールが InnoDB メモリ構造の 4 つの主要コンポーネントの 1 つであることを示しています。これは MySQL のサーバー層に属さず、InnoDB ストレージエンジン層のバッファプールです。」したがって、MySQL 8.0で削除された「クエリキャッシュ」機能とは異なります。

1. バッファプールとは何ですか?

「バッファプールは [バッファプール、BP と略記されます]。BP は、最もホットなデータページ (データページ) とインデックスページ (インデックスページ) をキャッシュする単位としてページページを使用します。ページページのデフォルトサイズは 16K です。 BP はリンクリストデータ構造を使用します。ページの管理」。

上の図は innoDB 内のバッファープールの場所を示しており、その場所からそのワークフローを大まかに知ることができます。

すべてのデータページの読み取りおよび書き込み操作は、バッファプールを通じて実行する必要があります。

Innodb の読み取り操作では、最初にデータのデータページがbuffer_pool に存在するかどうかを確認し、存在しない場合はディスクからバッファプールにページを読み取ります。

Innodb の書き込み操作は、まずデータとログをバッファプールとログバッファに書き込み、次にバックグラウンドスレッドがバッファの内容を一定の頻度でディスクにフラッシュします。「このフラッシュメカニズムはチェックポイントと呼ばれます。」

書き込み操作のトランザクション耐久性は、REDO ログディスクの配置によって保証され、バッファプールは読み取りおよび書き込みの効率を向上させる目的でのみ使用されます。

「バッファプールはテーブルデータとインデックスデータをキャッシュし、ディスク上のデータをバッファプールにロードし、アクセスごとのディスク IO を回避し、アクセスを高速化します。」

バッファプールとはメモリ領域のことであり、「ディスクアクセスを軽減する仕組み」**です。
データベースの読み取りと書き込みは、UNDO ログ/REDO ログ/REDO ログバッファ/binlog と併用されるバッファプール上で実行され、データは後でハードディスクにフラッシュされます。
バッファプールのデフォルトサイズは 128M で、データページ (16KB) をキャッシュするために使用されます。

show variables like 'innodb_buffer%';

バッファプールはInnoDBのデータキャッシュで、「インデックスページ」や「データページ」をキャッシュするほか、アンドゥページ、挿入キャッシュ、アダプティブハッシュインデックス、ロック情報などが含まれます。

"バッファプール内のほとんどのページはデータページ (インデックスページを含む) です。 "

「Innodb には、REDO ログを保存するためのログバッファもあります。」

2. バッファプール制御ブロック

データページはバッファプールにキャッシュされます。データページのサイズは、ディスク上のデフォルトのデータページサイズ (16K) と同じです。キャッシュページをより適切に管理するために、バッファプールには「データ記述領域」があります。

「InnoDB は、キャッシュされたデータページごとに個別の領域を作成し、データページが属するテーブルスペース、データページ番号、バッファプール内のキャッシュページのアドレス、リンクリストなどのデータページのメタデータ情報を記録します。ノード情報、一部のロック情報、LSN情報などが含まれるこの領域をコントロールブロックと呼びます。

「コントロールブロックとキャッシュページは 1 対 1 に対応しています。両方ともバッファプールに格納されます。コントロールブロックはバッファプールの前に格納され、キャッシュページはバッファプールの後ろに格納されます。」バッファプール。」

制御ブロックはキャッシュページサイズの約 5% (約 16 * 1024 * 0.05 = 819 バイト) を占めます。

上図はコントロールブロックとデータページの対応関係を示したもので、コントロールブロックとデータページの間に断片的なスペースがあることが分かります。

ここで疑問が生じるかもしれません。なぜ空間が断片化されているのでしょうか?

前述したように、データページのサイズは 16KB、コントロールブロックは約 800 バイトであるため、すべてのコントロールブロックとデータページを分割すると、コントロールブロックとキャッシュページのペアに十分ではない領域が残る可能性があります。部分それは単なる余分な断片化されたスペースです。バッファープールのサイズが適切に設定されている場合、断片化は発生しない可能性があります。

3. バッファプールの管理

「バッファプールには、LRU リンクリスト、フリーリンクリスト、フラッシュリンクリストの 3 つのリンクリストがあります。InnoDB は、これら 3 つのリンクリストを使用してデータページの更新と削除を制御します。」

3.1 バッファプールの初期化

「Mysql サーバーを起動するときは、バッファプールの初期化プロセスを完了する必要があります。つまり、バッファプールのメモリ空間を割り当て、それを制御ブロックとキャッシュページのいくつかのペアに分割します。」

「領域の申請」 Mysqlサーバーが起動すると、設定されたバッファプールサイズ(innodb_buffer_pool_size)に基づいて、バッファプールのメモリ領域としてオペレーティングシステムに「連続メモリ領域の申請」を行います。ここで適用されるメモリ空間が innodb_buffer_pool_size よりも大きくなる理由は、主に各キャッシュページの制御ブロックも格納されるためです。
「領域の分割」メモリ領域の適用が完了すると、データベースは、デフォルトのキャッシュページサイズの 16KB と、対応する制御ブロックサイズの約 800 バイトに従って、バッファプール内のいくつかの「制御ブロック」に分割されます。 & バッファページ] 右」**。

領域分割後のバッファプールのキャッシュページはすべて空であり、データの追加、削除、変更、確認が行われると、そのデータに対応するページがディスクファイルから読み出されて配置されます。バッファに格納され、プール内のキャッシュページに格納されます。

3.2 無料リンクリスト

「バッファプールが最初に初期化されるとき、内部のデータページと制御ブロックは空です。」読み取りと書き込みが実行されると、ディスクのデータページがバッファプールのデータページにロードされます。 BufferPool の中央データがハードディスクに保存された後、これらのデータページは再び解放されます。

上記のプロセスで問題が発生します。どのデータページが空で、どのデータページにデータがあるかをどのように知ることができますか。空のデータページを見つけることによってのみ、データを書き込むことができます。1 つの方法は、すべてのデータページを走査することです。経験によると、 , 一般的に言えば、その全体を横断する限り、追求するプログラマにとっては間違いなく耐えられないことになりますが、innoDB の開発者は間違いなくさらに耐えられないことになるため、無料のリンクリストがあります。

3.2.1 フリーリンクリストとは何ですか?

「フリーリンクリストは、フリーリンクリストです。これは、基本ノードといくつかのサブノードで構成される双方向リンクリストです。フリーデータページに対応する制御ブロック情報を記録します。」次のように

無料リンクリストの役割: 無料のキャッシュページを見つけるのに役立ちます
「ベースノード」
「これは、別途適用されたメモリ空間（約 40 バイトを占有）です。バッファプールの連続メモリ空間にはありません。」
リンクリスト内の子ノードの先頭ノードのアドレスと末尾ノードのアドレス、および現在のリンクリスト内のノードの数などの情報が含まれます。
「子ノード」
「各ノードは、空きキャッシュページの制御ブロックです。つまり、キャッシュページが空きである限り、その制御ブロックは空きリンクリストに配置されます。」
各制御ブロックには、free_pre (前のノードを指す) と free_next (次のノードを指す) の 2 つのポインターがあります。

フリーリンクリストの目的は、バッファプール内のデータページを記述することであるため、次の図に示すように、フリーリンクリストとデータページの間には 1 対 1 の対応関係があります。

上図はフリーデータページを記録するフリーリンクリストの対応関係を示したものですが、このコントロールブロックがバッファプールに1コピー、フリーリンクリストに1コピーあると誤解される可能性があります。メモリ内に同一のコントロールが存在するブロック「そう思ったら、完全に間違っています。」

"誤解"

フリーリンクリスト自体は、実際にはバッファプール内の制御ブロックで構成されています。前述したように、各制御ブロックには 2 つのポインタ free_pre/free_next があり、それぞれ前のフリーリンクリストと次のフリーリンクリストのノードを指します。ノード。"

「バッファプール内の制御ブロックは、2 つのポインタを介してすべての制御ブロックをフリーリンクリストに文字列化できます。図面をよりわかりやすくするために、フリーリンクリストの別のコピーを描画して、それらの間のポインタを表しました。関係。"

「これに基づくと、実際の関係図は次のようになります。」 :

ここで両方の絵が描かれている理由は、インターネット上の多くのブログで描かれている絵が上記と同様であり、「バッファプールやフリーリンクリストに制御ブロックがあるかのような誤解を与えるからです」とのこと。私も最初はそんな疑問を抱いたので、ここに解説し記録しておきます。

3.2.2 ディスクページをBufferPoolのキャッシュにロードするプロセス

フリーリンクリストを通じてディスクページを BufferPool キャッシュにロードするには、次の 3 つの手順のみが必要です。

"第一歩"

「空き制御ブロックと対応するバッファページを空きリストから取得します。」

"ステップ2"

「ディスク上のデータページを対応するキャッシュページに読み取り、同時に関連する記述データをキャッシュページの制御ブロックに書き込みます (例: ページが配置されているテーブルスペース、ページ番号、その他の情報) ）。」

「ステップ3」

「リンクリストから制御ブロックに対応する空きリンクリストノードを削除すると、バッファページが使用されたことを示します。」

以下では、疑似コードを使用して、制御ブロックがフリーリンクリストノードからどのように削除されるかを説明します。制御ブロックの構造は次のとおりであると仮定します。

/**
 *  控制块
 */
publicclass CommandBlock {
    
    
    /**
     *  控制块id,也就是自己，可以理解为当前控制块的地址，
     */
    private  String blockId;
    /**
     *  Free链表中当前控制块的上一个节点地址
     */
    private  String freePre;
    /**
     *  Free链表中当前控制块的下一个节点地址
     */
    private  String freeNext;
}

制御ブロック n-1 があり、その前のノードが記述データブロック n-2、次のノードが記述データブロック n であるとすると、そのデータ構造は次のようになります。

/**
 *  控制块 n-1
 */
publicclass CommandBlock {
    
    
    /**
     *  控制块id,也就是自己，可以理解为当前控制块的地址 block_n-1，
     */
    blockId = block_n-1;
    /**
     *  Free链表中当前控制块的上一个节点地址 block_n-2
     */
    freePre = block_n-2;
    /**
     *  Free链表中当前控制块的下一个节点地址 block_n
     */
    freeNext = block_n;
}

上の図では、制御ブロック N を使用しています。これをフリーリンクリストから削除するには、block_n-1 の freeNext を null に設定するだけで済みます。これにより、block_n はリンクリストへの参照を失います。

/**
 *  控制块 n-1
 */
publicclass CommandBlock {
    
    
    /**
     *  控制块id,也就是自己，可以理解为当前控制块的地址 block_n-1，
     */
    blockId = block_n-1;
    /**
     *  Free链表中当前控制块的上一个节点地址 block_n-2
     */
    freePre = block_n-2;
    /**
     *  Free链表中当前控制块的下一个节点地址 block_n
     */
    freeNext = null;
}

3.2.3 データページがキャッシュされているかどうかを確認する方法

ディスクページが Free を介してバッファプールのキャッシュページにロードされることは理解しています。すべてのデータをディスクから読み取って、Free リンクリストを介してキャッシュページに書き込むことはできません。データページがすでに存在している可能性があります。では、データページをキャッシュする必要があるかどうかを判断するにはどうすればよいでしょうか?

「データベースは、テーブルスペース番号 + データページ番号をキーとし、キャッシュページ制御ブロックのアドレスを値として持つデータページキャッシュハッシュテーブルを提供します。」

#注意：value是控制块的地址，不是缓存页地址
{
    
    表空间号+数据页号:控制块的地址}

データページを使用する場合、まずデータページキャッシュハッシュテーブルを検索します。見つかった場合は、その値に基づいて制御ブロックが直接検索され、次に制御ブロックに基づいてキャッシュページが検索されます。見つからない場合は、キャッシュページが検索されます。、ディスクデータページが読み書きされ、キャッシュされ、最後にデータページキャッシュハッシュテーブルに書き込まれます。

「このプロセスでは、ステートメントが実行される場合、通常は次のプロセスを経ます。」

SQL ステートメント内のデータベース名とテーブル名によって、ロードされるデータページがどのテーブルスペースにあるかを知ることができます。
「テーブルスペース番号に従って、テーブル名自体が一貫性アルゴリズムを通じてインデックスルートノードのデータページ番号を取得します。」
次に、ルートノードのデータページ番号に基づいて次のレベルのデータページが見つかり、データページキャッシュハッシュテーブルから対応するキャッシュページアドレスを取得できます。
キャッシュページは、キャッシュページアドレスを通じてバッファプール内で見つけることができます。

重要な誤解! ！！重要な誤解! ！！重要な誤解! ！！重要なことを 3 回言います。上記の一貫性のあるハッシュアルゴリズムは、データディクショナリ内の [[現在検索されているデータのデータページ番号ではなく、ルートノードのページ番号] を参照します。] ルートノードのページを取得するときこの番号を指定すると、B+tree を介してレイヤーごとに検索します。次のレイヤーを見つける前に、データキャッシュハッシュテーブルを介してバッファプールに移動し、このレイヤーのデータページが存在するかどうかを確認します。存在しない場合は、ディスクからロードされます。

3.3 LRUリンクリスト

LRU リンクリストを理解する前に、まず 2 つの問題について考えます。

最初の質問: 前述したように、データページがディスクからバッファプールに読み取られるとき、対応する制御ブロックは空きリンクリストから削除されます。では、この制御ブロックは削除された後どこに配置されるのでしょうか?
2 番目の質問: バッファプールのサイズは 128MB です。バッファプール内のすべての空きデータページにデータが読み込まれた後、新しいデータはどのように処理されるべきですか?

上記の問題は両方とも、解決するには LRU リンクリストが必要です。これら 2 つの質問を含む LRU リンクリストを見てみましょう。

3.3.1 LRU リンクリストとは何ですか?

バッファプールは InnoDB に付属するキャッシュプールです。データの読み書きはバッファプールで行われ、バッファプール内のデータページが操作されます。ただし、バッファプールのサイズには制限があります (デフォルトは 128MB)。頻繁にアクセスされるデータの一部はバッファプールに残ることが予想されますが、アクセス頻度の低いデータの一部は解放され、他のデータをキャッシュするためにデータページを解放することが予想されます。

これに基づいて、InnoBD は、頻繁にアクセスされるデータをリンクリストの先頭に配置し、ほとんどアクセスされないデータをリンクリストの最後に配置する LRU (Least Recent Used) アルゴリズムを採用しています。十分なスペースがない場合、スペースを空けるために末尾から削除する必要があります。」

「LRU リンクリストは本質的に制御ブロックで構成されています。」

3.3.2 LRUリンクリストの書き込み処理

「データベースがデータページをディスクからバッファプールにロードすると、一部の変更情報も制御ブロックに書き込まれ、制御ブロックはフリーリンクリストから切り離され、LRU リンクリストに追加されます。」プロセスは次のとおりです。

プロセス全体を整理してみましょう。

「ステップ 1: テーブルスペース番号に基づいて、テーブル名自体が整合性アルゴリズムを通じてデータページ番号を取得します (ツリー検索プロセスはここでは省略されます)」
「ステップ 2: データページがデータページキャッシュハッシュテーブルを通じてロードされているかどうかを確認する」
「ステップ 3: フリーリストからコントロールブロックを取得する」
「ステップ 4: ディスクデータを読み取る」
「ステップ 6: 空きキャッシュページにデータを書き込む」
「ステップ 7: キャッシュページ情報を制御ブロックに書き戻す」
「ステップ 8: 空きリストからリターン制御ブロックを削除する」
「ステップ 9: フリーから削除されたコントロールブロックノードを LRU リンクリストに追加する」

3.3.3 LRUリンクリストの削除メカニズム

「LRU アルゴリズムの設計上の考え方は、リンクリストの先頭のノードが最も最近使用されたノードであり、リンクリストの末尾のノードが最も長い間使用されていないノードであるということです。十分なスペースがない場合、スペースを解放するために、最も長い間使用されていない端のノードが削除されます。」

「LRU アルゴリズムの目的は、アクセスされたキャッシュページを可能な限り上位にランク付けできるようにすることです。」

「LRUアルゴリズムの設計思想」
アクセスされたページがバッファプールにある場合、そのページに対応する制御ブロックは、LRUリンクリストの先頭ノードに移動されます。
アクセスされたページがバッファプールにない場合、制御ブロックを LRU リンクリストの先頭に置くことに加えて、LRU リンクリストの末尾のノードも削除する必要があります。
「LRUの導入プロセス」

データアクセスがあり、データページ 23 にアクセスします。データページ 23 はバッファプールにないため、ディスクがロードされた後、最後のページ 22 が削除され、次に 23 が先頭にロードされます。リンクされたリスト。
このとき、データページ７がアクセスされるが、これはデータページ７がリンクリスト内にある、つまりバッファプール内にあるため、データページ７をリンクリストの先頭に直接移動することができる。
下図に示すように、LRU リンクリストの長さは 22 で、ノードは 1 から 22 までのデータページ制御ブロックです。初期状態は次のとおりです。

以上が LUR リンクリストの実装プロセスですが、この方法は MySQL にとって問題があるため、MySQL では LRU リンクリストの単純な実装を直接使用せず、いくつかの改良を加えています。と説明します。

3.4 リンクされたリストをフラッシュする

前に説明したように、**「データの読み取りと書き込みは、最初にバッファープール内のキャッシュページ上で動作し、次にバックグラウンドスレッドを通じてダーティページをディスクに書き込み、それらをディスクに永続化します。つまり、ダーティページをフラッシュします。」ページ「** .

「ダーティページ: 書き込み操作を実行するとき、最初にキャッシュページが更新されます。このとき、キャッシュページとディスクページのデータは不一致になります。これは多くの場合ダーティページと呼ばれます。」

ダーティページが生成されるため、ディスクを更新する必要があります (これは多くの場合ダーティと呼ばれます)。どのキャッシュページをフラッシュする必要があるかを判断するにはどうすればよいですか? また、キャッシュされたすべてのページについて 100 年間ディスクを更新したり、ページを 1 つずつ走査して比較したりすることもできません。この方法は絶対にお勧めできません。この場合、リンクリストをフラッシュする必要があります。

3.4.1 フラッシュリンクリストとは何ですか?

「フラッシュリンクリストの構造はフリーリンクリストの構造と非常に似ており、これもベースノードと子ノードで構成されます。」

フラッシュリンクリストは双方向リンクリストであり、リンクリストノードは変更されたキャッシュページ (更新されたキャッシュページ) に対応する制御ブロックです。
フラッシュリンクリストの役割: フラッシュする必要があるダーティページとキャッシュページを見つけるのに役立ちます。
「ベースノード」：フリーリンクリストと同様に、最初のノードと最後のノードを結び付け、記述情報のブロックが何ブロックあるかを格納します。
「子ノード」
「各ノードは、ダーティページに対応する制御ブロックです。つまり、キャッシュページが変更されている限り、その制御ブロックはフラッシュリンクリストに配置されます。」
各制御ブロックには、pre (前のノードを指す) と next (次のノードを指す) の 2 つのポインターがあります。

前述したように、制御ブロックは実際にはバッファプール内にあります。制御ブロックは上位ノードと下位ノードの参照を通じてリンクリストを形成するため、子ノードを見つけるにはベースノードを 1 つずつたどるだけで済みます。クリーニングする必要があるデータページです。」

3.4.2 フラッシュリンクリスト書き込み処理

データを書き込むとき、ディスク IO の効率が非常に遅いことがわかっているため、MySQL はディスクを直接更新せず、次の 2 つの手順を実行します。

最初のステップ: バッファープール内のデータページを更新する (メモリ操作)。
ステップ 2: 更新操作を REDO ログに順次書き込みます (ディスク順次書き込み操作)。

この効率が最も高い。REDO ログを 1 秒あたり数万回連続して書き込むことは、大きな問題ではありません。

上図はデータページ更新時のフラッシュリンクリストの書き込み処理を説明していますが、実際には更新データがバッファプールにロードされていることを前提としています。事前に、このプロセスは最初にディスクを読み取りますか? 実際には、そうではありません。パフォーマンスを向上させ、ディスク IO を削減するために、MySQL は多くの最適化を行っています。データページがバッファプールに存在しない場合、書き込みバッファ (変更バッファ) を使用して、更新操作の具体的な実装原理については、別の記事で詳しく説明します。

「コントロールブロックがフラッシュリンクリストに追加されると、バックグラウンドスレッドがフラッシュリンクリストを横断して、ダーティページをディスクに書き込むことができます。」

3.5 バッファプールデータページ

3 種類のリンクリストとその使用方法について学習したので、「実際には、データを管理するためにバッファプールには 3 種類のデータページとリンクリストがある」と要約できます。

フリーページは、このデータページが使用されずに空であり、その制御ブロックがフリーリンクリストに配置されていることを意味します。
「クリーンページ」とは、このデータページが使用され、データがキャッシュされ、その制御ブロックが LRU リンクリストに配置されていることを意味します。
「ダーティページ」とは、このデータページが [使用され] かつ [変更され] ており、データページ内のデータとディスク上のデータが一致していないことを意味します。ダーティページのデータがディスクに書き込まれ、メモリデータがディスクデータと一致すると、そのページはクリーンページになります。「ダーティページの制御ブロックは、LRU リンクリストとフラッシュリンクリストの両方に存在します。」

Linux C/C++ バックエンドサーバー開発学習教材、教育ビデオ、学習ロードマップ (教材には、C/C++、Linux、golang テクノロジー、Nginx、ZeroMQ、MySQL、Redis、fastdfs、MongoDB、ZK、ストリーミングメディア、CDN、P2P、 K8S、Docker、TCP/IP、コルーチン、DPDK、ffmpeg など)、必要に応じて、ラーニングエクスチェンジグループ 739729163 を追加して受信できます。