MySQL Innodbの主な機能挿入バッファ

挿入バッファとは何ですか?
挿入バッファのトリガー条件は何ですか?
なぜ一意のインデックスにできないのでしょうか?
チェンジバッファの概念の紹介
挿入バッファを実装するにはどうすればいいですか?
補助インデックスの挿入処理?
挿入バッファをいつマージしますか?

挿入バッファとは何ですか?

挿入バッファは、InnoDB ストレージエンジンの重要な機能の 1 つです。挿入バッファはバッファプールの一部であると理解されることがよくあります。この理解は一方的です。挿入バッファの情報の一部はメモリ内にあり、他の部分はデータページなどの物理ページに存在します。

InnoDB では、テーブルに自動増分主キーがある場合、このテーブルのデフォルトの挿入は非常に高速であることがわかっています。ここで主キーは自動増分であることに注意してください。自動増分でない場合、挿入はランダムになり、データページ分割のオーバーヘッドが発生する可能性があります。このように、挿入は順次行われず、遅くなります。別の状況として、挿入する ID が連続的ではなくランダムである場合、自動増分主キーがあっても、挿入速度は特に速くなりません。

主キーと非クラスター化インデックスを持つテーブルを次のように定義します。

テーブルtを作成する(

整数の自動増分、

b varchar(30)、

主キー(a)、

キー（b）

);

主キー a に従ってデータを挿入する場合、非クラスター化インデックス (セカンダリインデックス b とも呼ばれる) の挿入は順次行われず、挿入パフォーマンスは必然的に低下します。

Innodb ストレージエンジンは、このような状況に備えて挿入バッファーを設計しました。非クラスター化インデックスの挿入または更新操作では、毎回インデックスページに挿入するのではなく、まず挿入された非クラスター化インデックスページがバッファープールにあるかどうかを判断します。ある場合は、直接挿入されます。ない場合は、まず挿入バッファーに入れて、この非クラスター化インデックスがリーフノードに挿入されたことをデータベースに通知します。実際には挿入されず、別の場所に格納されます。その後、挿入バッファーと補助インデックスリーフノードのマージ操作が、一定の頻度と状況で実行されます。この場合、複数のレコードの挿入を 1 つの操作にマージできることが多く、非クラスター化インデックスの個別挿入のパフォーマンスが大幅に向上します。

挿入バッファのトリガー条件は何ですか?

挿入バッファが使用されるには、2 つの条件を満たす必要があります。1 つ目は、インデックスがセカンダリインデックスであること、2 つ目は、インデックスが一意ではないことです。上記の 2 つの条件が満たされると、挿入バッファを使用してデータベースの挿入操作のパフォーマンスを向上させることができます。

ここで注意すべき点は、プログラムが大量の操作を実行しているときに MySQL データベースがクラッシュした場合、実際の非クラスター化インデックスにマージされていない挿入バッファが多数存在し、回復に長い時間がかかる可能性があるということです。

なぜ一意のインデックスにできないのでしょうか?

一意のインデックスがサポートされていない理由は、補助インデックスが一意のインデックスである場合、挿入時に一意性を検証する必要があるためです。一意性を検証すると、個別の読み取りが発生し、オーバーヘッドが増加するため、挿入バッファはコストに見合いません。

次のように、show engine innodb status を通じて挿入バッファの使用状況を確認できます。

mysql--root@localhost:dms_alimetadata 20:35:24>>エンジンのinnodbステータスを表示\G
-------------------------------------
挿入バッファとアダプティブハッシュインデックス
-------------------------------------
Ibuf: サイズ 1、フリーリストの長さ 0、セグメントサイズ 2、マージ 0
統合された操作:
 挿入 0、削除マーク 0、削除 0
破棄された操作:
 挿入 0、削除マーク 0、削除 0

サイズはマージされたレコードページの数を表し、フリーリストlenはフリーリストの長さを表し、セグメントサイズは現在の挿入バッファサイズが2*16KBであることを示しています。

チェンジバッファの概念の紹介

最新のMySQL5.7はすでに変更バッファをサポートしています。実際、これはinnodb 1.0.xで導入されました。この変更バッファは挿入バッファのアップグレードとして理解できます。つまり、挿入、削除、更新を含む一般的なDML言語をバッファリングでき、それぞれ挿入バッファ、削除バッファ、パージバッファに対応しています。

もちろん、変更バッファによって使用されるオブジェクトは、依然として一意ではない補助インデックスです。

ここでは更新操作を例に挙げます。更新プロセスは 2 つの部分に分けられます。

最初の部分は、レコードの delete_mask を削除済みとしてマークすることです。delete_mask についてご存じない場合は、4 月 9 日の記事をお読みください。 2 番目の部分は、実際にレコードを削除することです。

削除バッファは更新の最初のプロセスに対応し、パージバッファは 2 番目の部分に対応します。

Innodb では、パラメータ innodb_change_buffering を通じてさまざまなバッファオプションを有効にすることができます。このパラメータのオプション値は、挿入、削除、パージ、変更、すべて、なしなどです。このうち、挿入、削除、およびパージは上で説明した状況であり、変更は挿入と削除をオンにすることを意味し、すべてをオンにすることを意味します。デフォルトのパラメータは次のとおりです。

mysql--root@localhost:dms_alimetadata 21:13:37>>'%buffering%' のような変数を表示します。
        +-------------------------+-------+
| 変数名 | 値 |
+-------------------------+-------+
| innodb_change_buffering | すべて |
+-------------------------+-------+
セット内の1行（0.01秒）

innodb_change_buffer_max_size を通じて、change_buffer が使用するメモリの最大量を制御することもできます。このパラメータのデフォルト値は 25 (1/4) です。例は次のとおりです。

mysql--root@localhost:dms_alimetadata 21:20:52>>'%innodb_change_buffer_max_size%' のような変数を表示します。
+---------------------------------+-------+
| 変数名 | 値 |
+---------------------------------+-------+
| innodb_change_buffer_max_size | 25 |
+---------------------------------+-------+
セット内の 1 行 (0.00 秒)

上記の show engine innodb status コマンドの出力には、merged operation と discarded operation が表示されています。ここで、insert は挿入バッファ操作の数、delete mark は削除バッファ操作の数、delete はパージバッファ操作の数を示します。discarded operation は、変更バッファがマージされたときにテーブルが削除され、マージが不要であることを示します。

挿入バッファを実装するにはどうすればいいですか?

挿入バッファのデータ構造は B+ ツリーです。クラスター化インデックスと同様に、挿入バッファ B+ ツリーはグローバルに 1 つだけ存在し、すべてのテーブルの挿入バッファリングを担当します。この B+ ツリーは、共有テーブルスペース、つまり ibdata1 ファイルに配置されます。したがって、ibd ファイルを介してテーブルデータを復元しようとすると、テーブルの補助インデックスのデータが挿入バッファにまだ残っている可能性があるため、チェックテーブルが失敗する可能性があります。したがって、ibd ファイルを介してファイルを復元した後、テーブルの補助インデックスを再構築するために修復テーブル操作が必要です。

挿入バッファはツリーなので、リーフノードと非リーフノードが必要です。非リーフノードには、クエリの検索キー値が格納されます。その構造は次のとおりです。

+---------+------------+--------+
| スペース | マーカー | 値 |
+---------+------------+--------+

この構造は合計 9 バイトを占め、スペースは挿入するレコードが配置されているテーブルのテーブルスペース ID を表します。この ID は各テーブルが持つ必要がある一意の ID です。スペースは 4 バイトを占め、マーカーは古いバージョンの挿入バッファーとの互換性を保つために 1 バイトを占め、オフセットはページのオフセットを示すために 4 バイトを占めます。

補助インデックスの挿入処理?

補助インデックスをデータページに挿入する場合、データページがバッファープールになければ、InnoDB はルールに従って検索キーを構築し、挿入バッファーの B+ ツリーにレコードを挿入します。挿入プロセス中に、レコードを何らかの方法で構築する必要があります。挿入の最終結果は、次のようなレコードになります。

+---------+------------+-----------+---------+-------+-------+------+------+
| スペース | マーカー | 値 | メタデータ | | | | |
+---------+------------+-----------+---------+-------+-------+------+------+

最後に追加のメタデータフィールドと他の 4 つのフィールドがあることがわかります。まずはメタデータフィールドについて説明します。メタデータフィールドは 4 バイトを占め、各レコードが挿入バッファーに入る順序を並べ替えるために使用されます。5 列目から、実際に挿入されたレコードの各フィールドの値になります。したがって、単純なデータレコードと比較すると、挿入バッファーには 13 バイトのオーバーヘッドが追加で必要になります。

各マージ挿入バッファが確実に成功するためには、各補助インデックスページの使用可能領域をマークするための特別なデータページを設定する必要があります。このデータページのタイプは挿入バッファビットマップであり、多数の補助インデックスページの使用可能領域を追跡できます。ここで簡単に見てみましょう。その使い方は後ほど説明します。