mysqlの最適化(2) インデックスの最適化戦略

1: インデックス タイプ

インデックス: クイック クエリ用;

ノード レベル 1、2 の 0 乗

ノード レベル 1、2 の 1 乗

ノード レベル 3、2 の 2 乗

ノードは 2 の 3 乗の 4 階にあります

ノードは 2 の 4 乗

の 5 階にあります。 。 。

。 。 。

。 。 。

ノードのレベル 31、2 の 32 乗

合計は最大 42 億です

つまり、42 億の数値を最大 32 回チェックできます

通常のクエリには 21 億回必要です



これは- ----》B-treeインデックス

注: これは、広い観点から見ると、すべてバランスツリーを使用していますが、具体的な実装に関しては、各エンジンが若干異なります

。 、厳密に言えば、NDB エンジンは T-tree

Myisam を使用します。 innodb では、デフォルトで B-tree インデックスが使用されます



しかし、抽象的には ---B-tree システムは「ソートされた高速検索構造」として理解できます。



1.2 ハッシュインデックス春、はははは。 。 。ニマニマ。 。 。

メモリテーブルでは、デフォルトはハッシュインデックスです。
ハッシュの理論上のクエリ時間計算量はO(1)です



質問: ハッシュ検索は非常に効率的であるため、なぜすべてハッシュインデックスを使用しないのでしょうか?

回答:

1: ハッシュ関数によって計算された結果はランダムです。データがディスク上に配置されている場合は、
アルゴリズムを使用します。 。 。 。 。

たとえば、主キーが id の場合、id が増加するにつれて、
id に対応する行がディスク上にランダムに配置され、不規則に分散されます。 ！

ハッシュアルゴリズムはルールなしでディスクスペースを割り当てます! ！ ！

2: 範囲クエリは最適化できません。3: プレフィックスインデックスは使用できません。

たとえば、btree では、フィールド列の値が「hellopworld」であり、インデックスが追加されます

xx=helloword をクエリすると、当然インデックスを使用できます、xx= こんにちは、インデックスも使用できます。
(左接頭辞インデックス)

ハッシュ('helloword') とハッシュ('hello') の関係はまだランダムであるためです

4 : 並べ替えは最適化できません。

5 : つまり、インデックスを通じてデータの場所を取得するには、テーブルに戻ってデータを取得する必要があります。逆方向検索とは、ディレクトリが単なる辞書であり、実際にはもう一度ページをめくらなければならないことを意味します



2: btree インデックスのよくある誤解

2.1 where 条件でよく使用される列にインデックスを追加します

例: where cat_id=3 とPrice>100; //3 番目の列をクエリします。100 元を超える商品です

エラー: cat_id と、価格にインデックスを追加します。

エラー: 独立したインデックスであるため、cat_id または Price インデックスのみを使用できます。同時に使用できるのは 1 つだけです。

alter table addindex (cat_id)

alter table addindex(price)

alter table addindex(goods_id) ------------- --------------同時に使用できるのは 1 つだけです。 。 。 。 ジョイントインデックスは複数の列を全体の値として扱います

index (cat_id, Goods_name, Price) ------------------------- それぞれをさらに追加します列は全体の値とみなされます



2.2 複数の列にインデックスを作成した後、どの列がクエリされるかに関係なく、インデックスは機能します

エラー: インデックスが複数列インデックスで機能するには、左側のプレフィックス要件が必要です満たす必要があります。
/ //プレフィックス要件を作成します

index(a,b,c)を例にとります(順序に関係していることに注意してください)



ステートメント

インデックスが機能するかどうか



a=3の場合

はい、a列のみを使用します



a=3とb=5の場合

はい、a列とb列が使用されます



a=3、b=5、cの場合=4

はい、abc が使用されます



ここで b=3 / where c=4

いいえ



ここで a=3 と c=4

列 a はインデックスとして機能しますが、c はインデックスとして機能できません



ここで、a=3、b>10、c =7

A は使用でき、b は使用でき、C は使用できません



上記と同じ、ここで、a=3 および b は 'xxxx% のようになります' そして c=7

A は使用可能、B は使用可能、C は使用不可



理解を容易にするために、ABC はそれぞれ長さ 10 メートルの板、川の幅は 30 メートルであると仮定します

完全一致の場合、板の長さは 10 メートルです。

左のプレフィックスと範囲クエリの場合、板の長さは 5 メートルです。



川の反対側を渡れる場合は、それを接続してください。 , インデックスが使用できるかどうかがわかります。

上記の例のように、a=3、b>10、c=7 の場合、

ボードの長さは 10 メートル、A 列インデックスは機能します

AボードはBボードに正常に接続されており、Bボードのインデックスは機能します

Bボードが短く、Cボードに接続できません、
C列のインデックスが機能しません。

上記はmysqlの最適化(2)インデックス 最適化戦略の内容です、その他の関連コンテンツについては、PHP 中国語 Web サイト (m.sbmmt.com) にご注意ください。