InnoDB のアーキテクチャと機能の詳細な説明 (InnoDB ストレージ エンジンの読書メモの要約)

背景スレッド

•マスタースレッド

コア バックグラウンド スレッドは主に、バッファー プール データをディスクに非同期的に更新する役割を担います。たとえば、ダーティ ページの更新、挿入バッファーのマージ、元に戻すページのリサイクルなどです。

1 秒に 1 回の操作:

1. トランザクションがコミットされていない場合でも、ログ バッファーはディスクにフラッシュされます。この操作は常に実行されるため、トランザクションの規模に関係なく、コミット時間は非常に短くなります。

2. IO プレッシャーが非常に小さい場合 (1 秒以内に発生する IO 数が innodb_io_capacity の 5% 未満)、innodb_io_capacity の 5% の挿入バッファをマージします。

3. ダーティ ページ率が innodb_max_dirty_pages_cnt より大きい場合は、innodb_io_capacity バッファー プール内のダーティ ページをディスクにフラッシュします。それ以外の場合、innodb_adaptive_flush がオンになっていると、buf_flush_get_desired_flush_rate に基づいて、更新されるダーティ ページの適切な数が選択されます。

10秒ごとに操作:

1. 過去 10 秒間の IO 操作が innodb_io_capacity 未満の場合、innodb_io_capacity バッファー プール内のダーティ ページをディスクにフラッシュします。

2. 5% の innodb_io_capacity 挿入バッファをマージします。

3. ログ バッファをディスクにフラッシュします。

4. 不要な元に戻すページを削除します。

5. バッファ プール内のダーティ ページの割合が 70% を超える場合は、innodb_io_capacity ダーティ ページをディスクに再度更新します。それ以外の場合は、innodb_io_capacity の 10% のダーティ ページをフラッシュします。

バックグラウンド ループ (データベースがアイドル状態または閉じられている場合):

1. 不要な元に戻すページを削除します。

2. innodb_io_capacity 挿入バッファをマージします。

フラッシュループ（データベースアイドル）:

1. innodb_io_capacityダーティページを更新する

•IOスレッド

Innodb ストレージ エンジンは AIO を広範に使用し、IO スレッドは主に IO 要求のコールバックを担当します。 これは、innodb_read_io_threads および innodb_write_io_threads パラメータ リストを使用して調整できます。

•スレッドの削除

トランザクションがコミットされた後。このトランザクションに関連付けられた undolog は不要になる場合があります。パージ スレッドは、不要な UNDO ページをリサイクルするために使用されます。

•PageCleaner スレッド

ダーティページの更新を担当します。マスター スレッドの作業とユーザー クエリ スレッドのブロックを減らします。

メモリバッファプール

データベース内のページの変更操作では、まずバッファー プール内のページが変更され、その後、一定の頻度でディスクに更新されます。つまり、バッファ プール内のページが変更されるたびにディスクへのフラッシュバックをトリガーするのではなく、チェックポイント テクノロジを通じてディスクにフラッシュバックされます。バッファ プールのサイズは、innodb_buffer_pool_size を通じて構成できます。

バッファ プールのデータ ページ タイプには、データ ページ、インデックス ページ、元に戻すページ、挿入バッファ、アダプティブ ハッシュ インデックス、InnoDB に保存されるロック情報、および辞書情報が含まれます。

InnoDB ストレージ エンジンでは、複数のバッファー プール インスタンスが使用できるようになりました。これにより、異なるバッファ プール インスタンスにハッシュすることでロックの競合が軽減されます。このパラメータは innodb_buffer_pool_instance を介して設定できます。

バッファ プールは、LRU アルゴリズムを使用してデータベースによって管理される大きなメモリ領域です。しかし、完全なテーブルスキャンの操作を考慮します。したがって、単純な LRU アルゴリズムは採用されません。 LRU リストに追加された中間点の位置。新しく読み取られたページは、lru リストの先頭に直接配置されず、中間点の位置に配置されます。デフォルトでは、lru リストの長さの 5/8 です。パラメータ innodb_old_blocks_pct によって制御されます。

バッファを挿入

非クラスター化インデックスの挿入および更新操作の場合、Innodb ストレージ エンジンはインデックス ページに直接挿入するのではなく、挿入バッファーに挿入します。次に、挿入バッファと補助インデックス リーフ ノードが一定の頻度でマージされます。多くの場合、複数のランダム挿入が 1 つの操作に結合されます。非クラスター化インデックス挿入のパフォーマンスが大幅に向上しました。

Innodb は insertbuffer 条件を使用します:

• インデックスは非クラスター化インデックスです

•インデックスが一意ではありません（一意である場合は、一意性を保証するためにインデックスを見つける必要があります）

挿入バッファの内部実装

挿入バッファのデータ構造は B+ ツリーです。 MySQL 4.1 以降では、すべてのテーブルの補助インデックスのバッファ挿入を担当する B+ ツリーはグローバルに 1 つだけ存在します。また、このツリーは共有テーブルスペース (デフォルトでは ibdata1) に格納されます。したがって、独立表領域の ibd ファイルのみを使用して表データを復元すると、失敗する可能性があります。また、挿入バッファ データを通じてテーブル上の補助インデックスを復元する必要もあります。

挿入バッファの非リーフ ノードには、スペース (4 バイト) + マーカー (1 バイト) + オフセット (4 バイト) として構成されるクエリ キーが格納されます。 space はレコードが配置されているテーブルのテーブルスペース ID を示し、offset はページ オフセットを示します。マーカーは古いバージョンとの互換性を保つために使用されます。

挿入バッファーのリーフ ポイントは、スペース + マーカー + オフセット + メタデータ + レコードのように構成されます。スペース、マーカー、オフセットは上記と同じ意味を持ちます。メタデータの IBUF_REC_OFFSET_COUNT には 2 バイトの整数が格納され、レコードが挿入バッファに入る順序をソートするために使用されます。このシーケンスを再度参照すると、レコードの正しい値を取得できます。挿入バッファ リーフ ノードの 5 列目から、実際に挿入されたレコードが表示されます。

挿入バッファ インデックスを有効にすると、補助インデックス ページのレコードが挿入バッファ B+ ツリーに挿入されることがあります。バッファへの各マージ挿入が確実に成功するためには、各補助インデックス ページの使用可能な領域をマークする場所が必要です。バッファーの挿入は、バッファー ビットマップの挿入というタイプの特別なページでマークされます。各挿入バッファ ビットマップ ページは、16384 ページ、つまり 256 ゾーンを追跡するために使用されます。各挿入バッファ ビットマップ ページは、16384 ページのうちの 2 ページ目にあります。各補助インデックス ページはビット マップ内で 4 バイトを占め、主に使用可能な補助インデックス ページの数を示すために使用されます。

マージ挿入バッファ

挿入バッファ内のレコードは、次の場合に実際の補助インデックスにマージされます。

• 補助インデックス ページがバッファー プールに読み込まれます。

• 挿入バッファ ビットマップ ページが補助インデックス ページに空き領域がないことをトラックした場合。

• マスタースレッドのスケジューリング

この方法では、補助インデックス ページ上の複数のレコード操作が 1 つの操作で元の補助インデックス ページにマージされ、パフォーマンスが向上します。

ダブルライト

InsertBuffer は Innodb ストレージ エンジンのパフォーマンスを向上させ、2 回の書き込みによりデータ ページの信頼性を向上させます。

書き込み障害が発生した場合、REDO ログを通じて回復することはできないのだろうかと疑問に思うかもしれません。これは確かに解決策ですが、REDO ログには、オフセット 800 や 'aaa' レコードの書き込みなど、ページの物理的な操作が記録されることを知っておく必要があります。ただし、ページがすでに破損している場合は、やり直しても意味がありません。つまり、ページを変更する前に、そのページの正しいコピーがなければなりません。書き込みエラーが発生すると、まずそのページのコピーを通じてページが復元され、その後やり直されます。これが二重書き込みです。

ダブル書き込みは 2 つの部分で構成され、1 つはメモリ内のダブル書き込みバッファです。 残りの部分は、物理ディスク上の共有テーブル スペース内の 128 の連続したページで、メモリ (2M) と同じサイズです。バッファプール内のページを更新する際、ページはディスクに直接書き込まれるのではなく、二重書き込みバッファに memcpy されます。次に、1M のデータが二重書き込みバッファを介して 2 回に分けて共有テーブルスペースに書き込まれ、その後すぐに fsync が呼び出されてディスクが同期されます。共有表領域の二重書き込みページは連続しているため、この書き込みオーバーヘッドはそれほど大きくありません。ダブル書き込みページの書き込みが完了した後、ダブル書き込みバッファー内のページを各テーブルスペースに書き込むのは個別書き込みです。

ページをディスクに書き込むときにオペレーティング システムがクラッシュした場合。その後、リカバリ中に、共有表領域内の二重書き込みバッファ ページからページのコピーが見つかります。それを表領域にコピーし、REDO ログを適用します。

適応型ハッシュインデックス

Innodb ストレージ エンジンは、テーブルの各インデックス ページのクエリを監視し、ハッシュ インデックスを作成するとクエリ速度が向上する可能性があることを検出する場合があります。次に、アダプティブ ハッシュ インデックス (AHI) と呼ばれるハッシュ インデックスが作成されます。

AHI では、このページへの連続したアクセス パターンは同じでなければならないという要件があります。たとえば、(a, b) のような結合インデックスの場合、アクセス パターンは次のように有効にできます。

ここで、a = xxx

ここで、a = xxx、b = yyy

同じアクセス モードは、同じクエリ条件を意味します。上記のクエリ操作を交互に実行する場合。 AHIは確立されません。

さらに、AHIでは、同じパターンが100回アクセスされた場合、ページはパターンを通じてN回アクセスされる必要があります。ここで、N = ページ内のレコード数 * 1/16

隣接するページを更新

ダーティ ページを更新する場合、Innodb ストレージ エンジンは、そのページが配置されている領域内のすべてのページをチェックします。ダーティ ページの場合は、まとめて更新されます。

非同期IO

Innodb は非同期 IO を使用してディスク操作を処理します。

チェックポイントテクノロジー

データ損失を回避するために、トランザクション データベース システムでは通常、先行書き込みログ戦略が採用されます。つまり、トランザクションがコミットされると、最初に REDO ログが書き込まれ、次にページが変更されます。

ただし、REDO ログは無限に大きくなることはできず、バッファ値 (ディスクにフラッシュされていないダーティ ページ) は無限にはなりません。たとえ無限に大きくできたとしても、データベースがクラッシュした後は回復に長い時間がかかります。そこで、次の問題を解決できる Check Point テクノロジが必要になります。

• データベースの復旧時間を短縮します。

• バッファプールが不十分な場合、ダーティページはディスクにフラッシュされる可能性があります。

• REDO ログが利用できない場合 (REDO ログはリサイクルされます)、ダーティ ページをディスクにフラッシュします。

クラッシュ後にデータベースを再起動する場合、すべてのログをやり直す必要はありません。チェックポイントより前のページはディスクに更新されているため、データベースはチェックポイント後の REDO ログのみを回復する必要があります。これにより、回復時間が大幅に短縮されます。

Innodb の場合、バージョンは実際には LSN (ログ シーケンス番号) によって比較されます。 LSN は 8 バイトの数値です。 各ページには LSN があり、REDO ログにも LSN があり、チェックポイントにも LSN があります。これは次のコマンドで確認できます

mysql> エンジン innodb ステータスを表示します\G;

.............

ログシーケンス番号 92561351052

ログは 92561351052 までフラッシュされました

最後のチェックポイントは92561351052です

上記の InnoDb システム アーキテクチャと機能の詳細な説明 (Innodb ストレージ エンジンの読書メモの要約) は、編集者が皆さんと共有する内容のすべてです。参考になれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。