mysqlストレージエンジン - InnoDBの超詳細解説

デフォルトでデータベースで使用されるストレージ エンジンを確認したい場合は、コマンド

SHOW VARIABLES LIKE 'storage_engine';

1. InnoDB storage Engine

1# を使用できます。 ##. InnoDB はトランザクション データベースに推奨されるエンジンです

トランザクション セキュリティ テーブル (ACID) をサポートします

トランザクションの ACID 属性: アトミック性、一貫性、分離性、耐久性

a.

原子性: 原子性とは、この一連のステートメントがすべて実行されるか、またはまったく実行されないことを意味します。トランザクションの実行途中でエラーが発生した場合、データベースはその場所にロールバックされます。トランザクションが開始された場所。

実装: 主に、MySQ ログ システムのやり直しおよび元に戻すメカニズムに基づいています。トランザクションは、選択、クエリ、削除などの機能を持つ一連の SQL ステートメントです。ステートメントの実行ごとに 1 つのノードが存在します。たとえば、delete ステートメントが実行された後、トランザクションにレコードが保存され、このレコードには、いつ、何をしたかが保存されます。何か問題が発生した場合は、元の位置にロールバックされ、実行した内容は Redo に保存され、逆に実行できます。

b.

一貫性: トランザクションの開始および終了の前後で、データベースの整合性制約に違反しません。 （例：例えば、A が B に送金した場合、A がそのお金を差し引くが B が受け取らないということは不可能です。）

c.

Isolation: 同時に、 1 つのトランザクションは同じデータを要求できます。異なるトランザクションは互いに干渉しません。

分離が考慮されていない場合、いくつかの問題が発生します:

i.

ダーティ リード: トランザクションでの読み取りを指します。処理中にコミットされていない別のトランザクションのデータが読み取られます (トランザクションが特定のデータを複数回変更しており、このトランザクション内の複数の変更がまだコミットされていない場合、同時トランザクションがアクセスするようになります)このデータにより、2 つのトランザクションによって取得されたデータが不整合になります); (別のトランザクションのコミットされていないダーティ データを読み取ります)

ii.

Non-repeatable read: データベース内で確実にデータの場合、トランザクション範囲内の複数のクエリが異なるデータ値を返しました。これは、クエリ間隔中に別のトランザクションによって変更および送信されたためです (前のトランザクションによって送信されたデータが読み取られ、クエリされたデータはすべて同じデータでした) item)

iii,

仮想読み取り (ファントム読み取り) : トランザクションが独立して実行されていない場合に発生する現象です (例: トランザクション T1 がテーブル内のすべての行を読み取ります)。 「1」から「2」に変更されました。このとき、トランザクション T2 はテーブルにデータ項目の行を挿入しましたが、このデータ項目の値はまだ「1」のままで、データベースに送信されました。ユーザーがトランザクション T1 を操作した場合、変更されたばかりのデータを見ると、まだ変更されていない行が 1 つあることがわかります。実際、この行は、まるで幻覚を見ているかのように、トランザクション T2 から追加されたものです); (前のトランザクションによって送信されたデータが読み取られます) . 、全体としてのデータのバッチの場合)

d.

Persistence: トランザクションが完了すると、トランザクションによるデータベースへのすべての更新はデータベースに保存され、保存することはできません。ロールバック

#2

.InnoDB は mySQL のデフォルトのストレージ エンジンです#デフォルトの分離レベルは RR であり、RR のさらに 1 つ下のレベルです分離レベルでは、マルチバージョン同時実行制御 (MVCC) によって反復不能読み取りの問題が解決され、ギャップ ロック (つまり同時実行制御) が追加されてファントム読み取りの問題が解決されます。したがって、InnoDB の RR 分離レベルは、より優れた同時実行パフォーマンスを維持しながら、実際にはシリアル化レベルの効果を実現します。

MySQL データベースは 4 つの分離レベルを提供します:

a、

Serializable

(シリアル化): ダーティ リード、反復不可能な読み取り、およびファントム リードの発生を回避できます。 ##b, Repeatable read

(反復可能な読み取り): ダーティ リードと非反復読み取りの発生を回避できます;

c, Read commited

( read commit): ダーティ リードの発生を回避できます;

d, Read uncommitted

(read uncommitted): 最低レベル、いかなる状況下でも保証できません;

----d 分離レベルは高から低まであり、レベルが高くなるほど実行効率は低くなります。

3.InnoDB は行レベルのロックをサポートします

。

行レベルのロックは同時実行性を最大限にサポートできます。行レベルのロックはストレージ エンジン層によって実装されます。

ロック: ロックの主な機能は、共有リソースへの同時アクセスを管理し、トランザクション分離を実現することです。

タイプ: 共有ロック (読み取りロック)、排他的ロック (書き込みロック)

MySQL ロックの強度: テーブル レベルのロック (オーバーヘッドが低く、同時実行性が低い)、通常はサーバー層で実装されます

行レベルのロック (オーバーヘッドが高く、同時実行性が高い)、ストレージでのみ実装されますエンジン レベルの実装

4. InnoDB は、大量のデータを処理するための最大のパフォーマンス

を実現するように設計されています。

その CPU 効率は、どのディスクベースのリレーショナル データベース エンジンにも匹敵しない可能性があります

5. InnoDB ストレージ エンジンは、MySQL サーバーと完全に統合されています

# InnoDB ストレージ エンジンは、データとインデックスをメイン メモリにキャッシュするための独自のバッファ プールを維持します。 InnoDB はテーブルとインデックスを論理テーブル スペースに配置し、テーブル スペースには複数のファイル (または元のディスク ファイル) を含めることができます。

6

、

InnoDB は完全な外部キーをサポートします。拘束＃＃＃＃＃＃

テーブルにデータを格納する場合、各テーブルは主キーの順に格納されますが、テーブル定義に主キーが表示されていない場合は主キーを指定してください。 InnoDB は行ごとに 6 バイトの ROWID を生成し、それを主キーとして使用します

#7. InnoDB は、高いパフォーマンスを必要とする多くの大規模データベース サイトで使用されています

#8. テーブル内の行数は InnoDB に保存されません

(例: テーブルから count(*) を選択するとき、InnoDB はテーブル全体をスキャンして行数を計算する必要があります); クリアするときテーブル全体、InnoDB は 1 行 1 行の削除は非常に遅い; InnoDB はディレクトリを作成しません InnoDB を使用すると、MySQL は ibdata1 という名前の 10MB の自動拡張データ ファイルを作成し、ib_logfile0 という名前のデータ ファイルを 2 つ作成します。 MySQL データ ディレクトリと ib_logfile1

2 の 5MB ログ ファイル InnoDB エンジンの基盤となる実装

InnoDB には 2 つのストレージ ファイルがあり、サフィックス名は です。 frm と .idb. ; このうち、.frm はテーブルの定義ファイル、.idb はテーブルのデータファイルです。

1. InnoDB エンジンはインデックス構造として B ツリー構造を使用します

B-Tree (バランス型マルチパス検索ツリー): ディスクなどの外部ストレージ デバイス用に設計されたバランス型検索ツリー

システムがディスクからメモリにデータを読み取るときの基本単位はディスク ブロックであり、同じディスク ブロックにあるデータはオンデマンドではなく一度に読み出されます。

InnoDB ストレージ エンジンは、データ読み取り単位としてページを使用します。ページは、ディスク管理の最小単位です。デフォルトのページ サイズは 16k です。

システム内のディスク ブロックのストレージ スペースは、多くの場合、そのため、InnoDB がディスク領域を申請するたびに、ページ サイズが 16 KB に達するまで、アドレスを持つ複数の連続したディスク ブロックが使用されます。

InnoDB は、ディスク データをディスクに読み取るときに基本単位としてページを使用します。データをクエリするときに、ページ内の各データがデータ レコードの場所を特定するのに役立つ場合、これにより、ページの数が削減されます。ディスク I/O によりクエリ効率が向上します。

B ツリー構造内のデータにより、システムはデータが配置されているディスク ブロックを効率的に見つけることができます。

B ツリー内の各ノードには大量のキーワード情報を含めることができます。例

各ノードはディスク領域の 1 つのディスク ブロックを占有します。ノードには 2 つの昇順キーとルートへの 3 つのポインタがあります。ポインタ 格納されるのは、子ノードが配置されているディスク ブロックのアドレスです。

ルート ノードを例にとります。キーワードは 17 と 35 です。P1 ポインタが指すサブツリーのデータ範囲は 17 未満です。P2 ポインタが指すサブツリーのデータ範囲は 17 です。 ----35. P3 ポインターのデータ範囲は 17----35. ポイントされたサブツリーのデータ範囲は 35 より大きい;

キーワード 29 の検索プロセスをシミュレートします:

a. ルート ノードに従ってディスク ブロック 1 を見つけ、メモリに読み取ります。 [初めてのディスク I/O 操作]

b. 区間 (17,35) のキーワード 29 を比較し、ディスク ブロック 1 のポインタ P2 を見つけます;

c. それを見つけますP2 ポインタ ディスク ブロック 3 に基づいて、メモリに読み込まれます。 [2 回目のディスク I/O 操作]

d. 区間 (26, 30) のキーワード 29 を比較し、ディスク ブロック 3 のポインタ P2 を見つけます;

e. ベースの検索P2 ポインタのディスク ブロック 8、メモリに読み込まれます。 [3 番目のディスク I/O 操作]

f. ディスク ブロック 8 のキーワード リストでキーワード 29 を検索します。

MySQL の InnoDB ストレージ エンジンはルートを使用するように設計されています。ノードは次の場所に存在します。したがって、ツリーの深さは 3 を超えてはなりません。つまり、I/O は 3 回を超える必要はありません。

上記の結果を分析すると、3 回のディスク I/O 操作と 3 回の I/O 操作が行われることがわかります。メモリサーチが動作する必要があります。メモリ内のキーワードは順序付きリスト構造であるため、バイナリ検索を使用して効率を向上させることができます。3 つのディスク I/O 操作が B ツリー全体の検索効率に影響を与える決定的な要因となります。

B ツリー

B ツリーは B ツリーに基づいて最適化されており、外部ストレージ インデックス構造の実装により適しています。各 B ツリーにはキーとデータはノードに格納されており、各ページの格納スペースには限りがあるため、データ データが大きい場合、各ノード (つまり 1 ページ) に格納できるキーの数は非常に少なくなります。保存されるデータの量が多い場合、B ツリーの深さも大きくなり、クエリ中のディスク I/O の数が増加し、クエリの効率に影響します。

B ツリーでは、すべてのデータ レコード ノードがキー値の順に同じ階層のリーフ ノードに保存され、キー値の情報のみが非リーフ ノードに保存されるため、各ノードの記憶容量が大幅に増加します。キー値の数により B ツリーの高さが減ります;

通常、B ツリーには 2 つのヘッド ポインタがあり、1 つはルート ノードを指し、もう 1 つはルート ノードを指します。は最小の key を持つリーフ ノードを指し、すべてのリーフ ノード (つまりデータ ノード) の間にチェーン リング構造があります。

したがって、B Tree では、主キーの範囲検索とページング検索、およびルート ノードから開始するランダム検索の 2 つの検索操作を実行できます。

InnoDB の B ツリー

InnoDB は ID によってインデックス付けされたデータ ストレージです

InnoDB エンジンを使用する 2 つのデータ ストレージ ファイルがあります。1 つは定義ファイル、もう 1 つは定義ファイルです。データドキュメント。

InnoDB は B ツリー構造を通じて ID のインデックスを構築し、レコードをリーフ ノードに保存します

インデックス付きフィールドが主キー ID ではない場合は、フィールドのインデックスを作成し、レコードの主キーをリーフ ノードに格納し、主キー インデックスを通じて対応するレコードを検索します。

その他の関連する質問については、PHP 中国語 Web サイトをご覧ください: PHP ビデオ チュートリアル

以上がmysqlストレージエンジン - InnoDBの超詳細解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。