MySQLインデックスの詳しい説明

MySQL のインデックスは B+tree を介しています。 B+tree はバランス型バイナリ ツリーの一種であるため、クエリ速度が非常に高速です。

インデックスは主にクラスター化インデックスと補助インデックスに分けられます:

クラスター化インデックス: mysqlのデータは主キーのクラスター化インデックスを介して保存されるため、リーフノードは各行のデータを保存するため、主キーを使用します。

これが非常に高速である理由は、主キーがクラスター化インデックスであるためですが、実際の使用では、そのような B+ ツリーが 1 つだけ構築されるため、主キーが一意である理由が説明できます。

インターネット上の画像の引用:

各層での検索は IO 操作であり、一般的に B+tree 層の数は 2 ～ 4 であるため、最悪の場合のみ実行する必要があります。 4 回の IO 操作。

補助インデックス: 補助インデックスとクラスター化インデックスの違いは、すべてのデータがリーフ ノードに保存されるわけではなく、データの場所が保存されることです。これは、補助インデックスを使用してデータを検索し、クラスター化インデックスのツリーを通じて詳細情報を検索することと同じです。

インターネット上の画像からの引用:

この画像は論理的な画像ですが、最下層はリーフ ノードを介してクラスター化インデックスを指します。つまり、最初のタイプの画像を通過する必要があります。次は

ロジック。

最終結果は、クラスター化インデックス ツリーを指す複数の補助インデックス ツリーになります

(図は本当に醜いです)

いつインデックスを作成すべきかについて

これはツリーなので、 through 二分探索法で検索するため、whereの条件として使用するのに適しており、値の範囲も広く、インデックスを作成するのに適しています。範囲が狭いもの (is_delete、sex などの列挙型) には適していません。

特定の状況については、show Index を通じて分析できます:

show index from company_related_person

結果:

次にカーディナリティを通じて計算します

select 105/(select count(*) from company_related_person) from DUAL

ここで得られた結果は 0.913 です (この値はストレージ容量に関連しており、これが最適です)この値が 1 に近いほど、インデックスの効率が高くなります。計算された値が非常に小さい場合は、インデックスを作成しないことをお勧めします

Explain

EXPLAIN select * from company_related_person where company_id='2'

Output

によるインデックス key は現在使用されているインデックス列を表します。最後の追加は、どのメソッドが使用されるかを示します。ここで、「インデックスを使用」は、ディスクが直接読み取られることを示します。 。

SQL パフォーマンス最適化の目標: 少なくとも範囲レベルに達すること。要件は参照レベルであり、const にできればそれが最善です。

1) 定数 1 つのテーブルには一致する行 (主キーまたは一意のインデックス) が最大 1 つあり、最適化フェーズ中にデータを読み取ることができます。

2) ref は、通常のインデックスの使用を指します。

3) range はインデックスの範囲取得を実行します

4) インデックスはディスクから直接読み取ることを意味します

上の図からも、ref を使用していることがわかります

インデックスとキーの違いについて:

インデックスを作成するときに、「インデックスとキーの違いは何ですか?」という質問がよくあります。 。キーは、主キー (Primary Key)、外部キー (Foreign Key) など、データの整合性チェックや一意性制約に使用される、リレーショナル モデル理論の一部であるキー値です。インデックスは実装レベルにあります。たとえば、テーブルの任意の列にインデックスを付けることができ、インデックス付きの列が SQL ステートメントの Where 条件に含まれる場合、データの場所を高速に取得できるようになります。 Unique Index については、インデックスの 1 つの種類にすぎません。Unique Index の確立は、この列のデータを繰り返すことができないことを意味します。

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