mysqlストレージエンジン - InnoDBの超詳細解説-mysql チュートリアル-php.cn

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

SHOW VARIABLES LIKE &#39;storage_engine&#39;;

ログイン後にコピー

1. InnoDB storage Engine

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

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

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

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

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

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

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

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

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

ii.

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

iii,

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

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

.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 はテーブルとインデックスを論理テーブルスペースに配置し、テーブルスペースには複数のファイル (または元のディスクファイル) を含めることができます。

、

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 ツリー内の各ノードには大量のキーワード情報を含めることができます。例

mysqlストレージエンジン - InnoDBの超詳細解説各ノードはディスク領域の 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 ツリーの高さが減ります;

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