MysqlのInnoDBエンジン-5。インデックス（2）

B +ツリーインデックス

B +ツリーインデックスの本質は、データベースでのB +ツリーの実現です。ただし、データベース内のB +ツリーインデックスの特性はファンアウトが大きいため、データベースでは、B +ツリーのレイヤーの高さは通常2番目から4番目のレイヤーにあります。つまり、行レコードの特定のキー値のクエリには、最大で2〜4回必要です。 IO。B +ツリーインデックスは、クラスター化インデックスと補助インデックスに分かれています。

クラスター化インデックス

クラスタ化インデックスは、データテーブルの主キーに従ってB +ツリーを構築することです。同時に、リーフノードはテーブル全体の行レコードデータを格納し、クラスタ化インデックスのリーフノードもデータページに変換されます。

クラスタ化インデックスのストレージは、物理的に連続的ではなく、論理的に連続的です。

• ページは二重にリンクされたリストによって接続され、ページは主キーの順序でソートされます。
• 各ページのレコードも二重にリンクされたリストを通じて維持され、物理的なストレージも主キーに従わずに保存できます。

セカンダリインデックス

補助インデックスは非クラスター化インデックスとも呼ばれ、リーフノードには行レコードのすべてのデータが含まれていません。リーフノードのキー値に加えて、各リーフノードのインデックス行にはブックマークも含まれています。

ブックマークは、インデックスに対応する行データの検索場所をInnoDBストレージエンジンに伝えるために使用されます。保存された特定のコンテンツは、クラスター化インデックスのキーです。

セカンダリインデックスの存在はクラスタ化インデックス内のデータの編成に影響しないため、各テーブルは複数のセカンダリインデックスを作成できます。セカンダリインデックスを介してデータをクエリする場合、InnoBDはまずセカンダリインデックスを介してプライマリキーインデックスのプライマリキーをクエリし、次にプライマリキーを渡します。完全な行レコードを見つけるためのインデックス。

インデックス管理

テーブルの変更またはインデックスの作成/削除を通じて、インデックスを作成または削除します。テーブルのインデックスは、show index from table_nameで確認できます。結果は次のとおりです。

• テーブル：インデックスが配置されているテーブル名
• Non_unique：非ユニークインデックス、primary_keyは0、非ユニークインデックスが1の場合
• Key_name：インデックスの名前
• Seq_in_index：インデックス内の列の位置
• Column_name：インデックス列の名前
• 照合順序：列がインデックスに格納される方法。AまたはNULLを指定できます。B +ツリーインデックスはAであり、ソートされます。NULLはソートされていないことを意味します（適応ハッシュインデックスなど）
• カーディナリティ：インデックスで一貫しているデータの推定値を表します。カーディナリティ/テーブルの行数は可能な限り1に近く、非常に小さい場合、このインデックスの重要性は非常に小さくなります。
• サブパート：列の部分インデックスであるかどうかにかかわらず、NULLでない場合は、列の最初のN文字にインデックスを付けることを意味します。
• パック：キーワードの圧縮方法。圧縮がない場合、NULL
• NULL：インデックス列にNULL値が含まれているかどうか。含まれている場合、NULL値を許可できることを意味します
• Index_type：インデックスタイプ、InnoDBはB +ツリーインデックスのみをサポートします
• コメント：コメント情報

カーディナリティ

カーディナリティ値は、インデックスに繰り返し記録されないデータの推定値を示します。カーディナリティ/テーブルのn行は、可能な限り1に近い必要があります。

統計カーディナリティはサンプリングによって行われます。カーディナリティ統計の更新は、挿入または更新操作中に発生しますが、毎回更新されるわけではありません。更新戦略は次のとおりです。

• テーブルの1/16のデータが変更されました。
• stat_modified_counter> 2000000000（stat_modified_counterは変更の数を記録するために使用されます）

カーディナリティサンプリングはインデックスの8つのリーフノードに基づいており、8つのノードを介してすべてのリーフノードの合計を推定してカーディナリティ値を取得します。そのため、毎回取得される値は正確でなく、変更されません。

計算式カーディナリティー=（P1 + P2 + .... + P8）* A / 8    Pはサンプリングノード1〜8、Aはリーフノードの数です。

注：テーブルが十分に小さい場合、テーブルのインデックスリーフノードは8以下であり、毎回計算される値は同じになります。

索引の他の内容

高速なインデックス作成

5.5より前のMysqlデータベースでは、このようなDDL操作が追加または削除されました。プロセスは次のとおりです。

• 最初に一時テーブルを作成します。テーブル構造は、alter tableによって新しく定義された構造です。
• 次に、元のテーブルデータを一時テーブルにインポートします。
• 次に、元のテーブルを削除します
• 最後に、一時テーブルは元のテーブル名として名前が付けられます

このような操作を非常に大きなテーブルで実行すると、パフォーマンスが大幅に低下します。したがって、Fast Index Creation（FIC）のインデックス作成方法が最初になります。

補助インデックスを作成するには、対応するテーブルにSロックを追加します。インデックスの作成中にテーブルを再構築する必要はありません。インデックスを削除するには、内部ビューを更新し、補助インデックスのスペースを使用可能としてマークし、Mysqlデータベースの内部ビューでテーブルのインデックス定義を削除します。

注：一時テーブルによって作成される十分なスペースがあることを確認するために、一時テーブルによって作成されるディレクトリーはtmpdirパラメーターによって設定されます。FIC操作中にSロックが追加されるため、この時点ではデータのみを読み取ることができます。

オンラインスキーマの変更

オンラインアーキテクチャ変更（OSC）プロセス：

• init：初期化段階、検証作業、主キー外部キートリガーの検証など
• createCopyTable：元のテーブルと同じ新しいテーブルを作成します
• alterCopyTable：新しいインデックスや列の追加など、新しいテーブルを作成するための変更操作
• createDeltasTable：デルタテーブルを作成します。トリガーを作成するために、元のテーブルに対するDML操作がデルタに記録されます。
• createTriggers：トリガーを作成します。トリガー操作によって生成されたレコードは、デルタテーブルに書き込まれます。
• startSnpshotXact：OSC操作トランザクションを開始します。
• selectTableIntoOutFile：元のテーブルデータを新しいテーブルに書き込みます（元のテーブルをロックする時間を短縮するために、シャーディング（複数のデフォルトシャーディング500000を介して複数の外部ファイルにデータを出力します））
• dropNCIndexs：新しいテーブルをインポートする前に、新しいテーブルのすべての補助インデックスを削除します
• loadCopyTable：エクスポートされたフラグメントデータを新しいテーブルにインポートします。
• replayChanges：OSCプロセスの元のテーブルのDML操作のレコードが新しいテーブルに適用され、これらのレコードはデルタに保存されます。
• recreateNCIndexs：セカンダリインデックスを再作成します
• replayChanges：DMLログを再度再生しますこれらのログは、補助インデックスを作成する上記のプロセス中に新しく生成されます。
• swapTables：元のテーブルと新しいテーブルの名前を交換します。2つのテーブルをロックする必要があり、新しいデータは許可されません。（名前の変更は高速な操作であるため、ロック時間は非常に短いです）

オンラインDDL

5.6以降では、オンラインDDLがサポートされ、以下の操作はオンラインDDLを通じて解決できます。

• 補助インデックスの作成と削除
• 自己増加する値を変更する
• 外部キー制約を追加または削除する
• 列の名前を変更

特定の文法コンテンツは関連しています。ブログを確認してください：https :  //www.cnblogs.com/cchust/p/4639397.html