ホームページ >データベース >mysql チュートリアル >MySQL の InnoDB ストレージ エンジンの詳細な紹介 (コード例)
この記事では、MySQL の InnoDB ストレージ エンジンについて詳しく説明します (コード例)。必要な方は参考にしてください。
InnoDB は MySQL のストレージ エンジン層に属し、プラグインの形式でデータベースに統合されます。 MySQL 5.5.8 以降、InnoDB がデフォルトのストレージ エンジンになります。 InnoDB ストレージ エンジンはトランザクションをサポートしており、その設計目標は主に OLTP アプリケーション向けです。その主な機能には、トランザクションのサポート、高同時実行性をサポートする行ロック設計、外部キーのサポート、自動クラッシュ回復、クラスター化インデックス構成テーブル構造などが含まれます。 (関連する推奨事項: MySQL チュートリアル )
システム アーキテクチャ
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> SHOW VARIABLES LIKE 'innodb_buffer_pool_size' \G *************************** 1. row *************************** Variable_name: innodb_buffer_pool_size Value: 134217728 1 row in set (0.01 sec)バッファ プールにキャッシュされるデータ ページのタイプは、インデックス ページ、アンドゥ ページ、挿入バッファ、アダプティブ ハッシュ インデックス、InnoDB ロック情報、データ ディクショナリ情報など。インデックス ページとデータ ページはバッファ プールの大部分を占めます。 REDO ログ バッファリングバッファ プール内のページ データがディスクよりも新しい場合、新しいデータをディスクにフラッシュする必要があります。 InnoDB は、ログ先行書き込み戦略を使用してデータを更新します。つまり、トランザクションが送信されると、まず REDO ログ バッファが一定の頻度でリセット ログ ファイルに書き込まれ、次にダーティ ページが書き込まれます。チェックポイント メカニズムに従ってディスクにフラッシュされます。 REDO ログ バッファーを非常に大きく設定する必要はありません。通常、8M でほとんどのアプリケーション シナリオに対応できます。 REDO ログは、リフレッシュをトリガーする次の 3 つの状況をサポートします。
InnoDB ストレージ エンジンでは、メモリ管理が行われます。ヒープ方式で実行されるメモリと呼ばれる処理。一部のデータ構造自体のメモリを割り当てる場合、追加のメモリプールから適用する必要がありますが、この領域のメモリが不足する場合はバッファプールから適用されます。
#ロックInnoDB でサポートされているロックは次のとおりです:
##共有ロックと排他ロックギャップ ロック
自動インクリメント ロック
トランザクション
ACIDトランザクションについて話すとき、トランザクションは OLTP としてのデータベースの最も重要な機能です。 ACID の特徴:Repeatable Read、このレベルは、同じトランザクション内で同じレコードを複数回読み取った結果の一貫性を保証し、InnoDB ストレージ エンジンでのファントム読み取りと非繰り返し読み取りの両方を解決します。質問を読んでください。
InnoDB エンジンは、Next-Key Lock
を使用してファントム読み取りの問題を解決します。 Next-Key Lock
は、行ロックとギャップ ロックの組み合わせです。InnoDB がインデックス レコードをスキャンするとき、最初に行ロック (レコード ロック) をインデックス レコードに追加し、次にギャップを追加します。インデックス レコードの両側のギャップ。ギャップ ロックを追加すると、他のトランザクションはこのギャップ内のレコードを変更したり挿入したりできなくなります。
Serializable はトランザクションを強制的にシリアルに実行することでファントム読み取りの問題を回避します。ただし、Serializable はデータの読み取り行ごとに実行されます。ロックされているため、多くのタイムアウトやロック競合の問題が発生する可能性があり、同時実行性が急激に低下するため、MySQL InnoDB での使用はお勧めできません。
#オープン トランザクションUndo ログ
trx_serial_list) のコミット トランザクション
insert undo の場合、
TRX_UNDO_TO_FREE としてマークされます。それ以外の場合、取り消しは更新取り消しであり、マークされます。
TRX_UNDO_TO_PURGE として。
TRX_UNDO_CACHED とマークされた取り消しは、エンジンによってリサイクルされます。
undo セグメント の
履歴リスト に入れ、
rseg_history_len## をインクリメントします # (グローバル)。同時に、ページの TRX_UNDO_TRX_NO
を更新します。データが削除された場合は、delete_mark
をリセットし、
から削除します。 TRX_UNDO_CACHED
としてマークされている場合は、update_undo_cached
キュー ## に追加します。 ##mtr_commit
(元に戻す/やり直しのログはパブリック バッファに書き込まれます) この時点で、ファイル レベルのトランザクションがコミットされます。この時点でクラッシュした場合でも、再起動後にトランザクションが送信されることが保証されます。次に行うことは、メモリ データ ステータスを更新することです (
読み取り専用トランザクションでは、
readview
を変更するだけで済みます。 global
構造内の情報をリセットします。読み取り/書き込みトランザクションは、まずトランザクション ステータスを TRX_STATE_COMMITTED_IN_MEMORY
に設定し、すべての行ロックを解放し、rw_trx_list
、readview
から trx_t
を削除する必要があります。グローバル readview
リンク リストから削除されました。 insert undo
がある場合は、ここで削除します。 update undo
がある場合は、パージ スレッドを起動して、ゴミをクリーンアップします。 最後に、trx_t# の情報をリセットします。 ## 簡単にダウンロードできるように、トランザクションは
を使用してロールバックします。
##From
update undoの間の最後の取り消しを検索し、この取り消しからロールバックを開始します
#update undo の場合、削除対象としてマークされたレコードはクリーニング対象としてマークされ、更新されたデータは最も古いバージョンにロールバックされます。
insert undo の場合は、クラスター化インデックスとセカンダリ インデックスを直接削除します
すべての元に戻す操作がロールバックされたか、指定された元に戻す操作にロールバックされた場合は、元に戻すログを停止して削除します
インデックス
InnoDB エンジンは、インデックス構造として B ツリーを使用します。主キー インデックスのリーフ ノード データ フィールドには完全なフィールド データが格納され、非主キー インデックスのリーフ ノードには、そのフィールドを指す値データが格納されます。主キー。
上の図は、InnoDB メイン インデックス (データ ファイルでもあります) の概略図であり、リーフ ノードに完全なデータ レコードが含まれていることがわかります。このインデックスはと呼ばれます。クラスター化インデックス。 InnoDB のデータ ファイル自体は主キーによって集約されるため、InnoDB ではテーブルに主キーが必要です。明示的に指定されていない場合、MySQL システムはデータ レコードを一意に識別できるカラムを主キーとして自動的に選択します。列が存在しない場合、MySQL は InnoDB テーブルの主キーとして暗黙的なフィールドを自動的に生成します。このフィールドの長さは 6 バイトで、型は long です。
InnoDB の補助インデックス データ フィールドには、アドレスの代わりに、対応するレコードの主キーの値が格納されます。つまり、InnoDB のすべてのセカンダリ インデックスは、データ フィールドとして主キーを参照します。クラスター化インデックスの実装により、主キーによる検索が非常に効率的になりますが、補助インデックス検索ではインデックスを 2 回取得する必要があります。まず、補助インデックスを取得して主キーを取得し、次に主キーを使用して主キー内のレコードを取得します。索引。
以上がMySQL の InnoDB ストレージ エンジンの詳細な紹介 (コード例)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。