インデックスの分類について簡単に説明していただけますか。
たとえば、基本的な使い方の観点から見ると、次のようになります。
- 主キー インデックス: InnoDB の主キーはデフォルトのインデックスです。データ列の繰り返しや NULL は許可されません。テーブルには主キーを 1 つだけ持つことができます。
- 一意のインデックス: データ列の重複は許可されず、NULL 値が許可され、テーブルでは複数の列が一意のインデックスを作成できます。
- 通常のインデックス: 基本的なインデックス タイプ、一意性の制限なし、NULL 値が許可されます。
- 結合インデックス: 複数の列値が結合検索用のインデックスを形成します。これはインデックスの結合よりも効率的です。
インデックスを使用するとクエリが高速化されるのはなぜですか?
従来のクエリ方法ではテーブルを順番に走査しますが、クエリされるデータの数に関係なく、MySQL はテーブル データを最初から最後まで走査する必要があります。
インデックスを追加した後、MySQL は通常、BTREE アルゴリズムを通じてインデックス ファイルを生成します。データベースにクエリを実行するときに、走査するインデックス ファイルを見つけて、比較的小さなインデックス データを検索し、それを対応するデータにマッピングします。検索の効率が向上します。
インデックス作成時の注意点は何ですか？
インデックスは SQL パフォーマンスを最適化するための強力なツールですが、インデックスのメンテナンスにもコストがかかるため、インデックスを作成するときは次の点にも注意する必要があります。
- インデックスはクエリが頻繁に使用されるフィールドに構築する必要があります
where判定、順序ソート、結合に使用する(on)フィールドにインデックスを作成します。
- インデックスの数は適切である必要があります
インデックスはスペースを占有するため、更新時にメンテナンスする必要があります。
- 性別など、区別性の低いフィールドにはインデックスを作成しないでください。
分散が低すぎるフィールドの場合、スキャンされる行の数は制限されます。
- 頻繁に更新される値は主キーまたはインデックスとして使用しないでください
インデックス ファイルの維持にはコストがかかり、ページ分割や IO 時間の増加にもつながります。
- インデックスを組み合わせることでハッシュ性（識別性）の高い値を前面に出す
左端のプレフィックスマッチング原則を満たすために
- 単一列インデックスを変更する代わりに、複合インデックスを作成します。
複合インデックスは複数の単一列インデックスを置き換えます (単一列インデックスの場合、MySQL は基本的に 1 つのインデックスしか使用できないため、複数の条件クエリが頻繁に使用される場合は複合インデックスを使用する方が適しています)
- フィールドが長すぎる場合は、プレフィックス インデックスを使用します。フィールド値が比較的長い場合、インデックス作成により多くのスペースが消費され、検索が非常に遅くなります。フィールドの前の部分をインターセプトすることでインデックスを作成できます。これはプレフィックス インデックスと呼ばれます。
- 順序のない値（ID カード、UUID など）をインデックスとして使用することは推奨されません
主キーが不確実な場合、リーフ ノードの頻繁な分割とディスク ストレージの断片化が発生します。
どのような状況でインデックスが失敗しますか?
- クエリ条件に or が含まれているため、インデックスが失敗する可能性があります
- フィールドの型が文字列の場合、where を引用符で囲む必要があります。そうしないと、暗黙的な型変換によりインデックスが無効になります。
- ワイルドカードなどはインデックス障害を引き起こす可能性があります。
- 結合インデックスでは、クエリの条件列が結合インデックスの最初の列ではないため、インデックスは無効になります。
- MySQL の組み込み関数をインデックス列で使用すると、インデックスが無効になります。
- インデックス付きの列に対する操作 (+、-、、/ など) の場合、インデックスは無効になります。
- インデックス フィールドで (!= または < >、not in) を使用すると、インデックス エラーが発生する可能性があります。
- インデックスフィールドで is null または is not null を使用すると、インデックスエラーが発生する可能性があります。
- 左結合クエリまたは右結合クエリに関連付けられたフィールドのエンコード形式が異なるため、インデックスエラーが発生する可能性があります。
- MySQL オプティマイザは、テーブル全体のスキャンを使用した方がインデックスを使用するよりも高速であると推定するため、インデックスは使用されません。
インデックスが適さないシナリオは何ですか?
- データ量が比較的少ないテーブルはインデックス付けには適していません
- 頻繁に更新されるフィールドはインデックス付けには適していません
- 離散性の低いフィールドはインデックス作成に適していません (性別など)
より多くのインデックスを構築した方がよいでしょうか?
もちろん違います。
- インデックスはディスク容量を占有します
- インデックスによりクエリの効率は向上しますが、テーブルの更新効率は低下します。たとえば、テーブルが追加、削除、または変更されるたびに、MySQL はデータを保存するだけでなく、対応するインデックス ファイルを保存または更新する必要があります。
通常のバイナリ ツリーの代わりに B+ ツリーを使用するのはなぜですか?
この問題は、クエリが十分に速いかどうか、効率が安定しているかどうか、保存されるデータの量、ディスクの検索回数など、いくつかの側面から見ることができます。
なぜ通常のバイナリツリーを使用しないのでしょうか?
通常の二分木は縮退しますが、リンクリストに縮退するとフルテーブルスキャンと同等になります。二分探索木と比較して、バランス二分木は検索効率がより安定し、全体的な検索速度が速くなります。
二分木のバランスを取ってみませんか?
データを読み取る場合、データはディスクからメモリに読み込まれます。ツリーのようなデータ構造をインデックスとして使用する場合、データを検索するたびにディスク (ディスク ブロック) からノードを読み取る必要がありますが、バランスのとれたバイナリ ツリーでは、ノードごとに 1 つのキー値とデータのみが保存されます。 B+ ツリーであれば、より多くのノード データを格納でき、ツリーの高さも低くなるため、ディスクの読み取り回数が減り、クエリ効率が向上します。
B ツリーではなく B+ ツリーを使用するのはなぜですか?
B-tree と比較して、B+ には次の利点があります。
- B Tree の亜種であり、B Tree で解決できるすべての問題を解決できます。
B Tree によって解決された 2 つの主要な問題: 各ノードにはより多くのキーワードとより多くのパスが保存されます
- データベースとテーブルをスキャンする強力な機能
テーブルに対して完全なテーブル スキャンを実行する場合は、リーフ ノードを走査するだけでよく、すべてのデータを取得するために B+ ツリー全体を走査する必要はありません。
- B+Tree は、B Tree よりも強力なディスク読み取りおよび書き込み機能を備えており、IO 回数が少なくなります。
ルート ノードとブランチ ノードはデータ領域を保存しないため、ノードはより多くのキーワードを保存し、一度にディスクからより多くのキーワードをロードし、必要な IO 回数を減らすことができます。
- 選別能力の向上
葉ノードには次のデータ領域へのポインタがあるため、データは連結リストを形成します。
- 効率がより安定します
B+Tree は常にリーフノードからデータを取得するため、IO 数は安定しています。
ハッシュインデックスとB+ツリーインデックスの違いは何ですか?
- B+ ツリーは範囲クエリを実行できますが、ハッシュ インデックスは実行できません。
- B+ ツリーはジョイント インデックスの左端の原則をサポートしますが、ハッシュ インデックスはサポートしません。
- B+ ツリーはソートによる順序をサポートしますが、ハッシュ インデックスはそれをサポートしません。
- ハッシュ インデックスは、同等のクエリにおいて B+ ツリーよりも効率的です。
- B+ ツリーがファジー クエリに like を使用する場合、like の後の単語 (% で始まるなど) が最適化の役割を果たす可能性があり、ハッシュ インデックスはファジー クエリをまったく実行できません。
クラスター化インデックスと非クラスター化インデックスの違いは何ですか?
まず、クラスター化インデックスは新しいインデックスではなく、データの保存方法であることを理解してください。クラスタリングとは、データ行と隣接するキー値がコンパクトにまとめて格納されることを意味します。私たちがよく知っている 2 つのストレージ エンジン - MyISAM は非クラスター化インデックスを使用し、InnoDB はクラスター化インデックスを使用します。
そうとも言える：
- インデックスのデータ構造はツリーです クラスター化インデックスのインデックスとデータはツリーに格納されます ツリーのリーフノードがデータです ノンクラスタードインデックスのインデックスとデータは同じツリー内にありません。
返品フォームを理解していますか？
InnoDB ストレージ エンジンでは、補助インデックス クエリを使用して、まず補助インデックスを通じて主キー インデックスのキー値を検索し、次に主キー値を使用して主キーの要件を満たすデータがないことを確認します。インデックス. 主キーに基づいてクエリより 1 つ多くのツリーをスキャンします インデックス. インデックス ツリー、このプロセスはテーブル バックと呼ばれます。
左端プレフィックス原則/左端一致原則とは何ですか?
注: 左端のプレフィックスの原則、左端のマッチングの原則、および左端のプレフィックスのマッチングの原則はすべて同じ概念です。
左端の一致原則: InnoDB の結合インデックスでは、クエリを実行するときに、次の値が一致する前に、前/左の値のみが一致します。
一番左のマッチング原則に従って、(a1, a2, a3) などの結合インデックスを作成します。これは、3 つのインデックス (a1)、(a1, a2)、および (a1, a2, a3) を作成するのと同じです。
なぜ左端から検索しないとマッチングできないのでしょうか？
たとえば、user テーブルがあり、名前と年齢を組み合わせたインデックスを作成します。
左端プレフィックス原則/左端一致原則とは何ですか?
注: 左端のプレフィックスの原則、左端のマッチングの原則、および左端のプレフィックスのマッチングの原則はすべて同じ概念です。
左端の一致原則: InnoDB の結合インデックスでは、クエリを実行するときに、次の値が一致する前に、前/左の値のみが一致します。
一番左のマッチング原則に従って、(a1, a2, a3) などの結合インデックスを作成します。これは、3 つのインデックス (a1)、(a1, a2)、および (a1, a2, a3) を作成するのと同じです。
なぜ左端から検索しないとマッチングできないのでしょうか？
たとえば、user テーブルがあり、名前と年齢を組み合わせたインデックスを作成します。
