InnoDB は、MySQL のデータベース エンジンの 1 つです。現在、MySQL のデフォルトのストレージ エンジンであり、MySQL AB によるバイナリ リリースの標準の 1 つです。InnoDB は、二重トラック認証システムを採用しており、1 つは GPL 認証です。もう 1 つは独自のソフトウェア認証です。 InnoDB は、トランザクション データベースに推奨されるエンジンであり、トランザクション セキュリティ テーブル (ACID) をサポートしています。InnoDB は、同時実行性を最大限にサポートできる行レベルのロックをサポートしています。行レベルのロックは、ストレージ エンジン層によって実装されます。
このチュートリアルの動作環境: Windows7 システム、mysql8 バージョン、Dell G3 コンピューター。
データベースでデフォルトで使用されるストレージ エンジンを確認したい場合は、コマンド SHOW VARIABLES LIKE 'storage_engine';
1. InnoDB ストレージ エンジンを使用できます。
InnoDB は MySQL のデータベース エンジンの 1 つで、現在は MySQL のデフォルトのストレージ エンジンであり、MySQL AB によるバイナリ リリースの標準の 1 つです。 InnoDB は Innobase Oy によって開発され、2006 年 5 月に Oracle に買収されました。従来の ISAM や MyISAM と比較して、InnoDB の最大の特徴は、PostgreSQL と同様に ACID 互換のトランザクション (Transaction) 機能をサポートしていることです。
InnoDB は、GPL ライセンスと独自ソフトウェア ライセンスの 2 つのライセンス システムを採用しています。
1. InnoDB はトランザクション データベースに推奨されるエンジンであり、トランザクション セキュリティ テーブル (ACID) をサポートします
トランザクションの ACID 属性: つまり、原子性と一貫性、隔離、耐久性
##トランザクションが開始された時点にロールバックします。
これは実装されています: は主に MySQ ログ システムの Redo および UNDO メカニズムに基づいています。トランザクションは、選択、クエリ、削除などの機能を持つ一連の SQL ステートメントです。ステートメントの実行ごとに 1 つのノードが存在します。たとえば、delete ステートメントが実行された後、トランザクションにレコードが保存され、このレコードには、いつ、何をしたかが保存されます。何か問題が発生した場合は、元の位置にロールバックされ、実行した内容は Redo に保存され、逆に実行できます。
## 異なるトランザクション間の干渉はありません。同じデータ;
###特定のデータが複数回変更されており、このトランザクションの複数の変更はまだありませんこのとき、同時トランザクションがデータにアクセスするため、2 つのトランザクションによって取得されたデータに不整合が生じます); (コミットされていないダーティ データを別のトランザクションから取得したと読み取ります)
##データ、トランザクション範囲内の複数のクエリは異なるデータ値を返しました。これは、クエリ間隔中に別のトランザクションによって変更および送信されたためです。(以前のトランザクションによって送信されたデータが読み取られ、同じデータ値はデータ項目) # Virtual Read(Phantom Read)#:トランザクションが個別に実行されないときに発生する現象です(例:トランザクションT1は、テーブルのすべての行を読み取ります。データ項目は「1から変更されました」このとき、トランザクション T2 はテーブルにデータ項目の行を挿入しましたが、このデータ項目の値はまだ「1」のままであり、データベースに送信されました。トランザクション T1 を操作するユーザーがデータを参照すると、それは変更されたばかりですが、変更されていない行がまだ 1 つあることがわかります。実際、この行はトランザクション T2 から追加されたもので、まるで幻覚を見ているかのようです。; : トランザクションが完了すると、データベースへのすべての更新が行われます。トランザクションによって保存されるデータはデータベースに保存され、ロールバックすることはできません 2. InnoDB は、mySQL のデフォルトのストレージ エンジンです。デフォルトの分離レベルは RR であり、RR では分離レベルを一歩進めるさらに、マルチバージョン同時実行制御 (MVCC) を使用して非反復読み取り問題を解決し、ギャップ ロック (つまり同時実行制御) を追加してファントム読み取り問題を解決します。したがって、InnoDB の RR 分離レベルは、より優れた同時実行パフォーマンスを維持しながら、実際にはシリアル化レベルの効果を実現します。 MySQL データベースは 4 つの分離レベルを提供します: a、Serializable (シリアル化): ダーティ リード、非反復読み取り、およびファントム リードの発生を回避できます。 ##b、Repeatable read (反復可能な読み取り): ダーティ リードおよび非反復読み取りの発生を回避できます; d、コミットされていない読み取り (コミットされていない読み取り): 最低レベル、いかなる状況でも保証なし; from a----d 分離レベルは高から低まで、レベルが高くなります実行効率が低くなります 3. InnoDB は行レベルのロックをサポートしています。行レベルのロックは同時実行性を最大限にサポートでき、行レベルのロックはストレージ エンジン層によって実装されます。 Lock: ロックの主な機能は、共有リソースへの同時アクセスを管理することであり、トランザクションの分離を実現するために使用されます ## MySQL ロックの強度 : テーブル レベルのロック (低オーバーヘッド、低同時実行性)、通常はサーバー層で実装されますただし、ストレージ エンジンでのみ実装されます。 level4. InnoDB は、大量のデータを処理する際に最大のパフォーマンスを発揮できるように設計されています。その CPU 効率は、ディスクベースのリレーショナル データベース エンジンの比類のないものです。 5. InnoDB ストレージ エンジンは、MySQL サーバーと完全に統合されています。InnoDB ストレージ エンジンは、メイン メモリにキャッシュされます。データとインデックス用に独自のバッファ プールを維持します。 InnoDB はテーブルとインデックスを論理テーブル スペースに配置します。テーブル スペースには複数のファイル (または元のディスク ファイル) を含めることができます。6. InnoDB は外部キーの整合性制約をサポートします。データを保存するときテーブルの定義時に主キーを指定しない場合、各テーブルは主キーの順に格納されます。 InnoDB は行ごとに 6 バイトの ROWID を生成し、それを主キーとして使用します #7. InnoDB は、高いパフォーマンスを必要とする多くの大規模データベース サイトで使用されています InnoDB はディレクトリを作成しません InnoDB を使用すると、MySQL は ibdata1 という名前の 10MB の自動的に拡張されたデータ ファイルを作成しますMySQL データ ディレクトリ、および ib_logfile0 および ib_logfile1
2 という名前の 2 つの 5MB ログ ファイル、InnoDB エンジンの基盤となる実装 InnoDB には 2 つのストレージ ファイルがあり、サフィックスは .frm と .idb です。.frm はテーブルの定義ファイル、.idb はテーブルのデータ ファイルです。 1. InnoDB エンジンは、インデックス構造 B ツリー (バランス型マルチパス検索ツリー) として B ツリー構造を使用します。外部ストレージ デバイス用に設計されたバランスの取れた検索ツリー システムがディスクからメモリにデータを読み取るとき、基本単位はディスク ブロック ビットです。同じディスクにあるデータブロックは、オンデマンドではなく定期的に読み取られると読み取られます。 InnoDB ストレージ エンジンは、データ読み取り単位としてページを使用します。ページはディスク管理の最小単位です。デフォルトのページ サイズは 16k です。 システム内のディスク ブロックのストレージ スペースはそれほど大きくないことが多いため、InnoDB がディスク スペースを申請するたびに、16 KB のページ サイズに達するまでアドレスを持つ複数の連続したディスク ブロックが使用されます。 InnoDB は、ディスク データをディスクに読み取るときに基本単位としてページを使用します。データをクエリするときに、ページ内の各データがデータ レコードの場所を特定するのに役立つ場合、ディスク I/O の数が減り、クエリの効率が向上します。 B ツリー構造内のデータにより、システムはデータが配置されているディスク ブロックを効率的に見つけることができます。 B ツリー構造内の各ノードB ツリーのベースとなる実際の状況には、大量のキーワード情報と分岐が含まれる場合があります。例:
各ノードは 1 つのディスク ブロック領域を占有し、ノード上には 2 つの昇順キーとサブツリーのルート ノードへの 3 つのポインタがあり、これらのポインタには子ノードが配置されているディスク ブロックのアドレスが格納されます。 # ルート ノードを例にとります。キーワードは 17 と 35 です。P1 ポインタが指すサブツリーのデータ範囲は 17 未満です。P2 pointer指定されたサブツリーのデータ範囲は 17----35 で、P3 ポインタが指定したサブツリーのデータ範囲は 35 より大きい; 模擬検索キーワード プロセス 29: a. ルート ノードに基づいてディスク ブロック 1 を見つけ、メモリに読み込みます。 [最初のディスク I/O 操作] b. 区間 (17,35) のキーワード 29 を比較し、ディスク ブロック 1 のポインタ P2 を見つけます; c. P2 ポインタに従ってディスク ブロック 3 を見つけ、それをメモリに読み取ります。 [2 回目のディスク I/O 操作] f. キーワード 29 がディスク ブロック 8 のキーワード リストで見つかりました。##MySQL の InnoDBストレージ エンジンはルート ノードをメモリ内に保持するように設計されているため、ツリーの深さが 3 を超えないように努めます。つまり、I/O が 3 回を超える必要はありません。 上記の結果を分析すると、3 回のディスク I/O 操作と 3 回のメモリ検索操作が必要であることがわかりました。メモリ内のキーワードは順序付きリスト構造であるため、バイナリ検索を使用して効率を向上させることができます。3 つのディスク I/O 操作が B ツリー全体の検索効率に影響を与える決定的な要因となります。
B ツリー B ツリーは、B ツリーに基づいて最適化されており、外部のストレージインデックス構造 B-Tree の各ノードにはキーとデータがあり、各ページのストレージスペースは限られています データデータが大きい場合、各ノード (つまり 1 ページ) に格納できるキーの数は非常に多くなります小さい。保存されるデータの量が多い場合、B ツリーの深さも大きくなり、クエリ中のディスク I/O の数が増加し、クエリの効率に影響します。 B ツリーには、B ツリーに基づいた 2 つの変更があります: ( 1)データはリーフノードに保存されています ## B Treeの非リーフノードはキー値情報のみを格納するため、各ディスクブロックに4つのキー値とポインタ情報を格納できると仮定すると、B Treeになった後の構造は以下のようになります。
通常、B ツリーには 2 つのヘッド ポインターがあり、1 つはルート ノードを指し、もう 1 つはリーフ ノードを指します。すべてのリーフ ノード (つまり、データ ノード) の間にチェーン リング構造があります。 したがって、B Tree では、主キーの範囲検索とページング検索、およびルート ノードから開始するランダム検索の 2 つの検索操作を実行できます。 #B InnoDB のツリー InnoDB は、ID ## によってインデックスが付けられたデータ ストレージです。 #InnoDB は、B ツリー構造を通じて ID のインデックスを構築し、レコードをリーフ ノードに保存します。
##インデックス付きフィールドが主キー ID ではない場合は、フィールドのインデックスを作成し、レコードの主キーをリーフ ノードに格納して、主キーを通じて対応するレコードを検索します。キー インデックス mysql ビデオ チュートリアル]
c、Read commit (読み取りコミット): ダーティ リードの発生を回避できます。 ;
以上がmysql innodbとは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。