データベースインデックスとは何ですか?データベースインデックスの詳しい説明-mysql チュートリアル-php.cn

インデックスとは何ですか?

データベースでは検索操作が非常に一般的であり、インデックス作成は検索速度を向上させる手段です。

インデックス分類

B+ツリーインデックス
これは伝統的な意味でのインデックスであり、最も一般的に使用され、最も効果的なインデックスです。
ハッシュインデックス
ハッシュインデックスは、テーブルの使用状況に基づいて自動的にハッシュインデックスを生成します。手動で介入する方法はありません。
全文インデックス
はキーワード検索の実装に使用されます。ただし、スペースに基づいて単語を分割することしかできないため、中国語はサポートされていません。
検索機能を実装するには、lucene を選択できます。
RTree インデックス
mysql ではほとんど使用されず、ジオメトリデータ型のみをサポートします。BTREE と比較して、RTREE の利点は範囲検索にあります。

B+Tree Index

データベースはページを記憶単位として使用し、1 ページは 8K (8192Byte) であり、1 ページに N 件のレコードを保存できます。
B+ ツリーでは、ページはデータページとインデックスページに分かれています。
B+ ツリーの高さは通常 2 ～ 4 レイヤーであるため、特定のキー値の行レコードの検索に必要な IO 時間は 2 ～ 4 回だけであり、非常に効率的です。

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

クラスター化インデックスでも非クラスター化インデックスでも、論理構造は B+ ツリーです。それらの唯一の違いは次のとおりです。

クラスター化インデックスのデータページ。完全なデータページレコードを格納します。つまり、クラスター化インデックスはテーブルの物理的な格納順序を決定します
非クラスター化インデックスのデータページには、レコードを指すアドレス情報とその実際のデータのみが格納されます。クラスター化インデックスに保存されています。

ジョイントインデックスとカバーインデックス

ジョイントインデックス
クエリ条件に複数の列が含まれる場合、ジョイントインデックスを使用できます。
カバリングインデックス
クラスター化インデックスを通じて特定のレコード情報を再度クエリすることなく、補助インデックスを通じてのみクエリしたい情報を取得できます。
カバーインデックスにはレコードの行全体が含まれていないため、そのサイズはクラスター化インデックスよりもはるかに小さくなります。
統計演算を行うのにより適しています。

MyISAM インデックスの実装

主キーインデックス
主キーインデックスでは、インデックスページには主キーが格納され、データページを指すオフセットには主キーと行のアドレスが格納されます。主キーが属するレコードスペース。
セカンダリインデックス
MyISAM では、プライマリインデックスとセカンダリインデックス (セカンダリキー) の間に構造的な違いはありません。ただし、プライマリインデックスではキーが一意である必要があるのに対し、セカンダリインデックスのキーは繰り返すことができる点が異なります。。

要約すると、MyISAM では、主キーインデックスであっても補助インデックスであっても、インデックスファイルとデータファイルはすべて非クラスター化インデックスとして保存されます。

InnoDB インデックスの実装

主キーインデックス
インデックスページには引き続き主キーとデータページを指すオフセットが保存されますが、データページには完全なレコードが保存されます。
つまり、InnoDB では、データと主キーのインデックスが一緒に保存されます。
補助インデックス
インデックスノードに格納される内容は同じで、キー値情報とデータページを指すオフセットのままですが、データページにはキー値情報とそれに対応する主キーが格納されます。キーの値。その後、主キーを使用して主キーインデックスをクエリすることにより、レコードを見つけることができます。

要約すると:

このクラスター化インデックスの実装方法により、主キーによる検索が非常に効率的になりますが、補助インデックス検索ではインデックスを 2 回取得する必要があります。最初に補助インデックスを取得して主キーを取得し、次に、主キーを使用して主インデックスを検索し、レコードを取得します。
InnoDB の補助インデックスには主キー列も含まれるため、主キーが比較的大きく定義されている場合、他のインデックスも大きくなります。テーブルに多数のインデックスを定義する場合は、主キーをできるだけ小さく定義するようにしてください。 InnoDB はインデックスを圧縮しません。

インデックスの利点

まず、一意のインデックスを作成することで、データベーステーブル内のデータの各行の一意性を保証できます。
2 番目に、データの取得を大幅に高速化できます。これがインデックスを作成する主な理由でもあります。
3 番目に、テーブル間の接続を高速化できます。これは、データの参照整合性を達成する上で特に意味があります。
4 番目に、データ取得にグループ化句と並べ替え句を使用すると、クエリでのグループ化と並べ替えにかかる時間も大幅に短縮できます。
5 番目に、インデックスを使用すると、クエリプロセス中に最適化非表示機能を使用してシステムのパフォーマンスを向上させることができます。

インデックスのデメリット

まず、インデックスの作成と維持に時間がかかり、データ量が増えると時間がかかります。
第 2 に、インデックスはデータテーブルが占有するデータ領域に加えて、物理領域も占有する必要があります。クラスター化インデックスを確立する場合、必要な領域は次のとおりです。もっと大きい。
3 番目に、テーブル内のデータを追加、削除、変更する場合、インデックスを動的に維持する必要があるため、データのメンテナンス速度が低下します。

インデックス作成が必要になるのはどのような状況ですか?

頻繁に検索が必要な列では、検索を高速化できます。
主キーである列では、列の一意性を強化し、データの配置構造を整理します。テーブル;
頻繁に検索される列接続された列で使用され、これらの列は主に外部キーとなり、接続を高速化できます
範囲に基づいて頻繁に検索する必要がある列にインデックスを作成します。インデックスはソートされており、指定された範囲は連続しているため、;
頻繁にソートが必要な列にインデックスを作成します。インデックスはソートされているため、クエリでインデックスのソートを使用してクエリのソートを高速化できます。 time;
WHERE句でよく使われる列にインデックスを作成し、条件の判定を高速化します。

インデックス作成が必要ないのはどのような状況ですか?

まず、クエリでほとんど使用または参照されない列にはインデックスを作成しないでください。これは、これらの列がほとんど使用されないため、インデックスを作成してもしなくてもクエリの速度は向上しないためです。逆に、インデックスの追加により、システムのメンテナンス速度が低下し、必要なスペースが増加します。
2 番目に、データ値が少ない列のインデックスは増加させるべきではありません。これは、クエリ結果ではこれらの列 (人事テーブルの性別列など) に含まれる値が非常に少ないため、結果セット内のデータ行がテーブル内のデータ行の大部分を占めるためです。テーブル内で検索する必要があるデータ行の割合が膨大です。インデックスを増やしても、検索が大幅に高速化されるわけではありません。
第三に、テキスト、イメージ、ビットのデータ型として定義された列にはインデックスを追加しないでください。これは、これらの列のデータ量が非常に大きいか、値が非常に少ないためです。
4 番目に、変更パフォーマンスが検索パフォーマンスよりはるかに大きい場合、インデックスは作成されるべきではありません。修正性能と検索性能は相反するものだからである。インデックスを追加すると、検索パフォーマンスは向上しますが、変更パフォーマンスは低下します。インデックスを減らすと、変更パフォーマンスは向上しますが、検索パフォーマンスは低下します。したがって、変更パフォーマンスが検索パフォーマンスよりもはるかに優れている場合は、インデックスを作成しないでください。

以上がデータベースインデックスとは何ですか?データベースインデックスの詳しい説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。