MySQL InnoDB ストレージエンジンの詳細

序文

MySQL では、InnoDB はストレージエンジンレイヤーに属し、プラグインとしてデータベースに統合されます。 MySQL 5.5.8 以降では、InnoDB がデフォルトのストレージエンジンになります。 InnoDB ストレージエンジンはトランザクションをサポートし、主に OLTP アプリケーション向けに設計されています。主な機能には、トランザクションのサポート、高同時実行性をサポートする行ロック設計、外部キーのサポート、自動クラッシュリカバリ、テーブル構造を整理するためのクラスター化インデックスなどがあります。

システムアーキテクチャ

InnoDB ストレージエンジンは、メモリプール、バックグラウンドスレッド、ディスクストレージの 3 つの部分で構成されます。

スレッド

InnoDB はマルチスレッドモデルを使用しており、バックグラウンドではさまざまなタスクの処理を担当する複数のスレッドが存在します。

マスタースレッド

マスタースレッドはコアバックグラウンドスレッドであり、主にバッファープール内のデータをディスクに非同期的に更新してデータの一貫性を確保する役割を担います。ダーティページの更新、マージ挿入バッファ、UNDO ページリサイクルなどが含まれます。

IO スレッド

InnoDB ストレージエンジンでは、書き込み IO 要求を処理するために非同期 IO (Async IO) が広く使用されています。IO スレッドの主な役割は、これらの IO 要求のコールバックを担当することです。

スレッドの削除

トランザクションがコミットされた後、トランザクションが使用する UNDO ログは不要になる可能性があるため、割り当てられて使用された UNDO ページを再利用するにはパージスレッドが必要になります。 InnoDB は複数のパージスレッドをサポートしており、これにより UNDO ページの回復が高速化され、CPU 使用率が向上し、ストレージエンジンのパフォーマンスが向上します。

ページクリーナースレッド

ページクリーナースレッドの役割は、マスタースレッドのダーティページリフレッシュ操作を置き換えることです。その目的は、元のマスタースレッドの作業とユーザークエリスレッドのブロックを減らし、InnoDB ストレージエンジンのパフォーマンスをさらに向上させることです。

メモリ

InnoDB ストレージエンジンのメモリ構造

バッファプール

InnoDB ストレージエンジンはディスクストレージに基づいており、その中のレコードをページ単位で管理します。ただし、CPU 速度とディスク速度の差により、ディスクベースのデータベースシステムでは通常、バッファープールレコードを使用してデータベースの全体的なパフォーマンスを向上させます。

バッファプールは実際にはメモリの速度を使用して、ディスク速度の遅さがデータベースのパフォーマンスに与える影響を補正します。データベースが読み取り操作を実行すると、ディスク上のページはまずバッファプールに配置されます。次に同じページが読み取られるときには、キャッシュとして機能するバッファプールからページデータが最初に取得されます。

データ変更操作では、まずバッファープール内のページデータが変更され、次にチェックポイントと呼ばれるメカニズムを使用してディスクに更新されます。

バッファプールのサイズは、データベースの全体的なパフォーマンスに直接影響します。InnoDB ストレージエンジンの場合、バッファプールの構成は、パラメータ innodb_buffer_pool_size によって設定されます。バッファプールの構成を表示するには、SHOW VARIABLES LIKE 'innodb_buffer_pool_size' コマンドを使用します。

mysql> 'innodb_buffer_pool_size' のような変数を表示 \G
************************** 1. 行 ****************************
変数名: innodb_buffer_pool_size
 値: 134217728
セット内の1行（0.01秒）

バッファプールにキャッシュされるデータページの種類には、インデックスページ、UNDO ページ、挿入バッファ、アダプティブハッシュインデックス、InnoDB ロック情報、データディクショナリ情報などがあります。インデックスページとデータページは、バッファプールの大部分を占めます。

REDOログバッファ

バッファプール内のページデータがディスクよりも新しい場合は、新しいデータをディスクにフラッシュする必要があります。 InnoDB は、先行書き込みログ戦略を使用してデータを更新します。つまり、トランザクションがコミットされると、最初に REDO ログバッファに書き込まれます。REDO ログバッファは一定の頻度でリセットログファイルに更新され、その後、チェックポイントメカニズムに従ってダーティページがディスクに更新されます。

REDO ログバッファを非常に大きく設定する必要はありません。通常、8M でほとんどのアプリケーションシナリオに対応できます。 REDO ログは、更新をトリガーする次の 3 つの状況をサポートします。

マスタースレッドは、1秒ごとにREDOログバッファをREDOログファイルにフラッシュします。
トランザクションがコミットされるたびに、REDOログバッファをREDOログファイルにフラッシュする
再実行ログバッファプールの残りスペースが1/2未満になると、再実行ログバッファは再実行ログファイルにフラッシュされます。

追加メモリプール

InnoDB ストレージエンジンでは、メモリはメモリヒープと呼ばれる方法で管理されます。一部のデータ構造自体にメモリを割り当てる場合、追加のメモリプールから適用する必要があります。この領域のメモリが不足する場合は、バッファプールから適用されます。

ロック

InnoDB でサポートされているロックは次のとおりです。

共有ロックと排他ロック
意図ロック
レコードロック
ギャップロック
自動増分ロック

共有ロックと排他ロック

InnoDB エンジンは、共有 (S) ロックと排他 (X) ロックという 2 つの標準的な行レベルロックを実装します。共有ロックでは、ロックを保持するトランザクションがデータ行を読み取ることができ、排他ロックでは、トランザクションがレコード行を書き込むことができます。

トランザクションが共有ロックを保持している場合、他のトランザクションはこのレコード行の共有ロックを取得できますが、このレコード行の排他ロックを取得することはできません。トランザクションが行の排他ロックを取得すると、他のトランザクションはこの行の共有ロックと排他ロックを取得できなくなります。

意図ロック

InnoDB では、インテンションロックはテーブルレベルのロックであり、共有ロックと排他ロックに分けられます。

意図的な共有ロック: 行の共有ロックを取得する
意図的排他ロック: 行の排他ロックを取得する

トランザクションは、共有/排他ロックを取得する前に、まず意図的な共有/排他ロックを取得する必要があります。意図的なロックは、テーブル上の他の操作をブロックしません。行に対して共有ロックまたは排他ロックを取得することを他のトランザクションに通知するだけです。

レコードロック

レコードロックはインデックスのロックです。レコード自体ではなく、レコードのインデックスをロックします。現在のテーブルにインデックスがない場合、InnoDB はテーブルに対して非表示のクラスター化インデックスを作成し、レコードロックはこの非表示のクラスター化インデックスをロックします。

ギャップロック

ギャップロックは、レコードロックと同様に、インデックスに対しても作用します。違いは、レコードロックは 1 つのインデックスレコードに対してのみ作用するのに対し、ギャップロックはインデックスの範囲をロックできることです。 InnoDB のギャップロックの唯一の機能は、他のトランザクションによるデータの挿入を防ぎ、ファントムリードを防止することです。

自動増分ロック

自動インクリメントロックは、自動インクリメント列を含む挿入操作でのみ機能する特別なテーブルレベルのロックです。トランザクションがデータを挿入している場合、他のトランザクションはトランザクション全体が挿入操作を完了するまで待機し、その後ロックを取得して挿入操作を実行する必要があります。

取引

酸

トランザクションは OLTP データベースの最も重要な機能です。トランザクションについて話すときは、ACID の 4 つの基本特性について言及する必要があります。

原子性: トランザクションにおける作業の最小単位。すべてが成功するか、すべてが失敗するかのいずれかです。
一貫性: トランザクションの開始後および終了後も、データベースの整合性は損なわれません。
分離: 異なるトランザクションは互いに影響を及ぼしません。分離レベルは RU (コミットされていない読み取り)、RC (コミットされた読み取り)、RR (繰り返し読み取り)、および SERIALIZABLE (シリアル化可能) の 4 つです。
耐久性: トランザクションがコミットされると、データへの変更は永続的になり、システムに障害が発生しても失われません。

InnoDB の原子性、永続性、一貫性は、主に Redo ログ、Undo ログ、およびコミット時の強制ログのメカニズムによって実現されます。 Redo ログはクラッシュ時にデータを回復するために使用され、Undo ログはトランザクションの影響を元に戻すために使用されます。また、マルチバージョン管理にも使用できます。コミット時の強制ログメカニズムにより、トランザクションがコミットされた後も Redo ログが保持されることが保証されます。分離はロックと MVCC によって確保されます。

分離レベル

MySQL には、次の 4 つのトランザクション分離レベルがあります。

コミットされていない読み取り
コミットされた読み取り
繰り返し読み取り
シリアル化可能

4 つの分離レベルを理解する前に、他の 3 つの用語を理解する必要があります。

ダーティリード

トランザクション a はトランザクション b がまだコミットしていないデータを読み取りますが、何らかの理由でトランザクション b がロールバックされます。このように、トランザクション a によって読み取られたデータは使用できず、異常な結果が発生します。

繰り返し不可能な読み取り

あるデータは a のトランザクションサイクル中に複数回クエリされ、同時にトランザクション b でこのデータが更新または削除されます。その場合、トランザクション a の各クエリの結果は異なる可能性があります。

ファントムリード

ファントムリードの結果は、実際には非反復読み取りの結果と同じです。違いは、非反復読み取りは主に他のトランザクションの編集（更新）と削除（削除）操作を実行することです。ファントムリードは主に挿入操作に使用されます。つまり、トランザクションのライフサイクル内で、別のトランザクションの新しく挿入されたデータが照会されます。

コミットされていない読み取り

コミットされていない読み取り。この場合、トランザクション a は別のトランザクション b のコミットされていないデータを見ることができます。この時点でトランザクション b がロールバックされると、トランザクション a はダーティデータを取得します。これがダーティリードの意味です。

この分離レベルは、通常、MySQL InnoDB では推奨されません。

コミットされた読み取り

コミットされた読み取り: トランザクションによって開始からコミットされるまでの間に行われた変更は、他のトランザクションには表示されません。ダーティリードの問題は解決されましたが、ファントムリードは依然として存在します。

繰り返し読み取り

繰り返し読み取り: このレベルでは、同じトランザクションで同じレコードを複数回読み取った結果の一貫性が確保されます。InnoDB ストレージエンジンのファントム読み取り問題と繰り返し不可能な読み取り問題の両方が解決されます。

InnoDB エンジンは、Next-Key Lock を使用してファントム読み取りの問題を解決します。ネクストキーロックは、行ロックとギャップロックの組み合わせです。InnoDB は、インデックスレコードをスキャンするときに、最初に行ロック (レコードロック) をインデックスレコードに追加し、次にインデックスレコードの両側のギャップにギャップロック (ギャップロック) を追加します。ギャップロックを追加すると、他のトランザクションはこのギャップ内のレコードを変更したり挿入したりできなくなります。

シリアル化可能

Serializable は最も高い分離レベルです。トランザクションを強制的にシリアルに実行することで、ファントムリードの問題を回避します。ただし、Serializable は読み取られるデータ行ごとにロックするため、多数のタイムアウトやロック競合の問題が発生する可能性があります。その結果、同時実行性が大幅に低下します。また、MySQL InnoDB で使用することも推奨されません。

取引を開く

開始、作業開始、取引開始

BEGIN コマンドを実行しても、実際にはエンジンレベルで新しいトランザクションが開始されるわけではなく、現在のスレッドに、明示的に開始されたトランザクションであることを示すマークが設定されるだけです。

トランザクション開始読み取り専用

読み取り専用トランザクションが有効になっている場合、MySQL サーバーはデータ変更の SQL を受信すると、データの変更を直接拒否し、エラーを返します。このエラーはエンジンレイヤーに入りません。

トランザクション開始読み取り書き込み

現在のスレッドの読み取り専用状態が true の場合、スーパーユーザーが読み取り/書き込みトランザクションを開始できるようにします。

一貫性のあるスナップショットでトランザクションを開始

トランザクションを開くと、エンジンレイヤーに入り、readview が開きます。この操作は RR 分離レベルでのみ有効です。それ以外の場合はエラーが報告されます。

元に戻すログ

データが変更されると、対応する UNDO ログが記録されます。トランザクションが失敗したりロールバックしたりした場合は、記録された UNDO ログを使用してロールバックできます。 UNDO ログは、変更前のデータイメージを記録する論理ログです。変更中に現在のデータを同時に読み取る必要がある場合は、バージョン情報に基づいて行に記録されたデータの以前のバージョンを分析できます。さらに、Undo ログも永続的に保護する必要があるため、Undo ログによって Redo ログも生成されます。

トランザクションコミット

グローバルトランザクションIDジェネレータを使用してトランザクション番号を生成し、現在の接続のトランザクションポインタ（trx_t）をグローバルコミット済みトランザクションリスト（trx_serial_list）に追加します。
元に戻すをマークします。このトランザクションが 1 つの UndoPage のみを使用し、使用量がページの 3/4 未満である場合は、このページを TRX_UNDO_CACHED としてマークします。要件を満たしておらず、挿入元に戻す場合は、TRX_UNDO_TO_FREE としてマークします。それ以外の場合、元に戻すが更新元に戻す場合は、TRX_UNDO_TO_PURGE としてマークします。 TRX_UNDO_CACHED としてマークされた元に戻す操作は、エンジンによってリサイクルされます。
更新の取り消しを undo セグメントの履歴リストに格納し、rseg_history_len (グローバル) を増分します。同時に、ページ上の TRX_UNDO_TRX_NO を更新し、データが削除された場合は delete_mark をリセットします。
update_undo_list から undate undo を削除します。TRX_UNDO_CACHED としてマークされている場合は、update_undo_cached キューに追加します。
mtr_commit (ログの undo/redo がパブリックバッファに書き込まれる) では、これまでのところ、トランザクションはファイルレベルでコミットされています。このとき、システムがクラッシュした場合でも、再起動後にトランザクションをコミットすることができます。次に行うことは、メモリデータのステータスを更新することです (trx_commit_in_memory)
読み取り専用トランザクションでは、グローバル読み取りビューリストから読み取りビューを削除し、trx_t 構造体の情報をリセットするだけで済みます。読み取り/書き込みトランザクションでは、まずトランザクション状態を TRX_STATE_COMMITTED_IN_MEMORY に設定し、すべての行ロックを解除して rw_trx_list から trx_t を削除し、グローバル readview リストから readview を削除する必要があります。挿入の取り消しがある場合は、ここで削除します。更新の取り消しがある場合は、Purge スレッドを起動してゴミをクリーンアップします。最後に、次のトランザクションのために trx_t の情報をリセットします。

ロールバック

読み取り専用トランザクションの場合は、直接戻ります。
トランザクション全体をロールバックするか、トランザクションの一部をロールバックするかを決定します。部分的なトランザクションの場合は、保持する必要がある Undo ログの数を記録し、余分なものをすべてロールバックします。
更新の元に戻すと挿入の元に戻すから最後の元に戻すを見つけ、この元に戻すからロールバックします。
更新を元に戻す場合は、削除済みとしてマークされたレコードがクリアされ、更新されたデータは最も古いバージョンにロールバックされます。挿入を元に戻す場合は、クラスター化インデックスとセカンダリインデックスを直接削除します。
すべての元に戻す操作がロールバックされた場合、または指定された元に戻す操作までロールバックされた場合は、元に戻すログを停止して削除します。

索引

InnoDB エンジンは、インデックス構造として B+ ツリーを使用します。主キーインデックスのリーフノードのデータドメインには完全なフィールドデータが保存され、非主キーインデックスのリーフノードには主キーを指す値データが格納されます。

上図は、InnoDB プライマリインデックス (データファイルでもある) の概略図です。リーフノードに完全なデータレコードが含まれていることがわかります。このタイプのインデックスは、クラスター化インデックスと呼ばれます。 InnoDB のデータファイル自体は主キーによってクラスタ化されるため、InnoDB ではテーブルに主キーが必要です。明示的に指定されていない場合、MySQL システムはデータレコードを一意に識別できる列を主キーとして自動的に選択します。そのような列が存在しない場合、MySQL は InnoDB テーブルの暗黙的なフィールドを主キーとして自動的に生成します。このフィールドは 6 バイト長で、長整数型です。

InnoDB のセカンダリインデックスデータフィールドには、アドレスではなく、対応するレコードのプライマリキーの値が格納されます。つまり、InnoDB のすべてのセカンダリインデックスは、データフィールドとしてプライマリキーを参照します。クラスター化インデックスの実装により、主キーによる検索は非常に効率的になりますが、補助インデックス検索には 2 つのインデックス検索が必要です。最初に補助インデックスを検索して主キーを取得し、次に主キーを使用して主インデックスからレコードを取得します。

結論

この記事では、MySQL InnoDB の多くの機能のうち、ほんの一部を紹介するだけです。興味のある学生は、「MySQL Technology Insider: InnoDB Storage Engine」を読んで、関連する知識をさらに学ぶことができます。

さて、以上がこの記事の全内容です。この記事の内容が皆さんの勉強や仕事に一定の参考学習価値を持つことを願っています。ご質問があれば、メッセージを残してコミュニケーションしてください。123WORDPRESS.COM をご愛顧いただきありがとうございます。

以下もご興味があるかもしれません: