MySQL InnoDB の重要なコンポーネントの概要

Innodbには以下のコンポーネントが含まれています

1. innodb_buffer_pool:

これは主にデータとインデックスをキャッシュするために使用されます (正確には、InnoDB のテーブルはクラスター化インデックスによって構成されているため、データは主キー インデックスのリーフ ノードのみです)。

2. バッファを変更する:

1 更新ステートメントがセカンダリインデックスのレコードを更新するが、レコードが配置されているページがinnodb_buffer_poolにない場合、innodbはセカンダリインデックスを更新します。

ページの更新アクションはinnodb_buffer_poolの特定の領域（変更バッファ）にキャッシュされ、別のトランザクションBが後でこのセカンダリインデックスページを読み取りたい場合、

ページはまだ innodb_buffer_pool にないため、トランザクション B はまずページを innodb_buffer_pool にロードし、ターゲット ページが innodb_buffer_pool に入るようにします。

次に、変更バッファの内容に応じてインデックス ページを更新できます。これにより、IO 操作が節約され、パフォーマンスが向上します。

2 もちろん、他のリフレッシュ メカニズム (変更バッファー内の変更がディスクに書き込まれる) もあります。たとえば、MySQL が比較的アイドル状態の場合、低速シャットダウン プロセス中にもリフレッシュされます。

バッファの内容をディスクに変更する

3 変更バッファの監視

エンジンの InnoDB ステータスを表示します。

-------------------------------------
挿入バッファとアダプティブハッシュインデックス
-------------------------------------
Ibuf: サイズ 1、フリーリストの長さ 0、セグメントサイズ 2、マージ 0
統合された操作:
 挿入 0、削除マーク 0、削除 0
破棄された操作:
 挿入 0、削除マーク 0、削除 0
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
ハッシュ テーブルのサイズは 34679、ノード ヒープには 0 個のバッファーがあります
0.00 ハッシュ検索/秒、0.00 非ハッシュ検索/秒
---
ログ
---
ログシーケンス番号 24635311
ログが 24635311 までフラッシュされました
ページ数は 24635311 まで増加しました
最後のチェックポイントは24635302
保留中のログ フラッシュ 0 件、保留中の chkp 書き込み 0 件
10 ログ I/O が完了しました。0.00 ログ I/O/秒

3. 適応ハッシュインデックス:

1 テーブル内の一部の行が非常に頻繁に使用される場合、InnoDBテーブルはB+ツリーで構成されているという事実により、最良のケースでは、InnoDBは最初にインデックスページを読み取り、次にデータページを読み取り、最後に

データを検索します。ハッシュインデックスは、B+ツリーインデックスのハッシュをキーとして使用し、B+ツリーインデックスの値（それが指すページ）を値として使用します。ハッシュインデックスの導入により、InnoDBはインデックスのハッシュを計算できます。

値はデータが配置されているページに直接配置されるため、範囲外の検索にはハッシュ インデックスが有利です。

2 InnoDB で bash インデックスを使用する場合は、いくつかの条件があります。1. innodb_adaptive_hash_index=1 に設定すると、InnoDB はハッシュ インデックスを有効にします。ただし、これは作業の半分にすぎません。

InnoDB はテーブル内のすべての行に対してハッシュ インデックスを作成するわけではありません。テーブル内の頻繁にアクセスされる行に対してのみハッシュ インデックスを作成します。コールド データに対してハッシュ インデックスを作成するのは無駄です。

innodb_adaptive_hash_index_parts はハッシュ インデックスのパーティションを設定でき、これにより同時実行性が向上します。

4. REDOログバッファ:

redoログバッファの内容は定期的にディスクにフラッシュされます。 redoログバッファを大きく設定すると、MySQLが大規模なトランザクションを処理するのに有利になります。その理由は、大規模なトランザクションの処理では、

ディスクに書き込む代わりに、REDO を REDO ログ バッファに書き込むことができます。メモリはディスクよりも高速なので、大規模なトランザクションをより高速に処理できます。つまり、REDO ログ バッファが大きくなります。

この場合、コミット前に不要なディスク フラッシュ操作を削減できます。

5. システム表領域:

innodbシステムテーブルスペースには、innodbデータディクショナリ、doublewrite\changebuffer\undologなどの一部のストレージ領域（innodb_file_per_tableの場合）が含まれます。

開かれていない場合、ユーザーが作成したテーブルはこのシステム テーブルスペースに保存されます。この場合、システム テーブルスペースには共有テーブルスペースも含まれると見なすことができます。

上記は、MySQL InnoDB の重要なコンポーネントの概要の詳細内容です。MySQL InnoDB コンポーネントの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。