【2023】MySQL の詳細 - SQL の最適化

索引

インデックスはデータ構造です

• インデックス作成の長所と短所:

インデックス構造:

私のSQLインデックスは主にB+TREEインデックスを参照しています

BTREE ツリー構造:

たとえば、フォークの数は 5 です。フォークはポインターを表し、各ノードは最大 4 つの要素を持つことができます (ノード要素の数 = M フォークの数は 1 未満です)。

B+TREE ツリー

 

MySQLのB+ツリー

MySQL インデックス データ構造は、古典的な B+Tree を最適化します。元の B+ ツリーに基づいて、隣接する要素を指すリンク リスト ポインタが追加され、連続したポインタを持つ B+ ツリーが形成され、インターバル パフォーマンスが提供されます。

指数の分類

• 単一値インデックス
• 複合インデックス
• 一意のインデックス

インデックス設計の原則:

• クエリ頻度の高いフィールドやデータ量の多いテーブルの場合
• インデックスフィールドの選択は、where句の条件から最適な候補列を抽出する必要があり、where句の組み合わせが多い場合は、最もよく使用される列の組み合わせでフィルタリング効果が最も高いものを選択する必要があります。
• 独自のインデックスを使用すると、識別度が高くなり、インデックスの使用効率が高くなります
• インデックスにより、追加、削除、変更の効率が低下します。
• 短いインデックスを使用する
• 左端のプレフィックスを使用する場合、複合インデックスの使用時に左端のプレフィックス ルールに従わない場合、インデックスは失敗します。

一番左のプレフィックス:

複数の列にインデックスが付けられている場合、クエリは中間インデックスをスキップせずに左端の列から開始する必要があることを示します。

左端の列から始まる条件がない場合、インデックスは失敗します。

途中にジャンプがある場合、後続のフィールドはインデックスを使用しません。

1. 順序に関係なく、左端の列のみを含める必要があります。

1. 範囲クエリの場合、右側の列はインデックスを使用しません（><を使用する場合は等号を使用しないでください）

1. インデックスに対して操作を実行できません。そうでない場合、インデックスは無効になります ()

1. 型変換 (例: string 型)。条件付きクエリを実行する場合、「 」を追加しなくても、自動的に int に変換されます。

2. * は使用せず、カバーするインデックスを使用してください (クエリのフィールドはすでにインデックスに含まれています)。

• クエリ対象のフィールドがインデックスを介してクエリされている場合、クエリがテーブルに返されると、フィールドがすでに存在していることがわかり、クエリはテーブルに返されません。インデックスを使用していない一部のフィールドがクエリされていないことがわかりました。その後、テーブル クエリに戻ります。

1. orで区切られた条件。または の前の条件内の列にインデックスがあるが、後続の列にインデックスがない場合、関連するインデックスは参照されません。

1. あいまい一致には like を使用します。末尾に % を追加するとインデックスに移動しますが、前に % を追加するとインデックスには移動しません。

1. mysql は、インデックスを使用しないほうがインデックスを使用するよりも高速であると判断した場合、たとえば次のような場合、インデックスを使用しません。クエリされたフィールドのほとんどが、指定した値である場合。- クエリ北京はインデックスに行かない

1. is null、is not null; 場合によっては失敗します。クエリされたフィールドのほとんどにデータがある場合、is null を使用するとインデックスが取得され、is not null を使用するとインデックスが取得されません。これは、フィールドのほとんどが非 null の Mysql であるためです。フルテーブルスキャンの方が速いと感じますが、

2. in はインデックスを使用します。not はインデックスを使用しません。原理は上記と同じです。

1. 日付を問い合わせる場合

関数を範囲に変更する必要があります。変更しない場合、インデックスは使用できません。