I.はじめに
この問題を説明するために、アラブ粉末は、インデックスが何であるかを見てあなたを取ります。
ちょうど学習データベースは、教師は書籍・カタログ・データベースのインデックスのアナロジーを使用したいとき、私は覚えている、とインデックスは、あなたがより迅速に検索したいデータを見つけてみましょう、ディレクトリのように私たちに伝えることができます。
インデックスが最初の接触であれば、アナロジーは、私たちは視覚的な印象を持つことができます。深くインデックスを知るために、私たちは考えであるインデックスディレクトリを保持し続けることができない場合でも、我々はインデックスイエスのどのような性質を考えるように飛び出します。
第二に、指標の性質
インデックスがない場合には、我々は、データはデータのみ、我々はデータの一部を読み取るために、ディスク上の適切な場所に行きたいという意味の各行を見て、ラインでスタートからフィニッシュラインに順に見つけることができます見つけます。
ディスクと、今後のクエリの2つの段階にクエリデータへのクエリは、その後、ディスクへの照会時間がクエリで、大容量のディスクIOを取っていることを意味クエリ条件、より時間よりもはるかに大きくなる場合時間の一部。より具体的には、クエリの効率は、ディスクIOの数で休憩を取るために、私たちは、クエリにできるだけディスクIOの数を減らすことができれば、我々は、クエリをスピードアップすることができます。
ioは、クエリをスピードアップすることができますディスクを減らす知って、私たちは、ディスクIOを削減する方法に焦点を当てます。元の表の行に応じてクエリ単語場合、nはクエリn回に必要なデータの断片、すなわち、ディスクIOの数を減少させるために、O（N）時間計算量で、我々は、より低いデータ構造に時間の複雑さを照会する必要がありますデータを保存します。
私たちは、インデックスを呼び出して、このクエリ時間複雑さの低いデータ構造、。人気だから、インデックスが実際に変更されるインデックスのデータ構造として機能することができ、データ構造のいくつかの種類です。
第三に、選択の指標
あなたがデータ構造のいくつかを理解している場合は、インデックスは、データ構造のクエリは、容易であるため、その後、高い確率が優先ツリー構造になります。結局、ツリー構造は、一般に、O（logN個）クエリ時間の複雑性を有し、データの挿入および欠失は、比較的平均的なパフォーマンスです。（あなたは、クエリの速度も高いああハッシュテーブルである配列を言うかもしれないが、後でこれを分析します）
我々はすでにInnoDBテーブルとMyISAMのようなMySQLの最も人気のあるエンジンを知っていますが、最終的指標としてB +木を選びましたが、ここで私は、インデックスとしてB +木を選んだ理由を推測最も一般的なバイナリを開始するつもりでした、インデックスとして動作する場合、いくつかの木の長所と短所を比較します。
二進木
最も一般的なバイナリツリーの問題は、我々は以下のチャートを見て、彼はO（logN個）クエリ時間の複雑さを保証できないということです。
要素が徐々に増加挿入要素の挿入のためには、右、良いバイナリツリーは、最終的になった常に「リスト」。この極端な場合には、バイナリツリーのクエリ時間の複雑さは、もはやO（logN個）ではありませんが、O（N）に減少し、これは明らかにされたインデックスの要件を満たしていません。
平衡二分木（赤黒木）
赤黒木のようなバランスのバイナリツリーは、いかなる場合に挿入要素は、彼はいくつかの手段によって樹高の回転を調整することができ、ツリー全体クエリ効率がO（logN個）に維持されるように、次のように：
それはそうすることは彼がインデックスを作成するために必要な条件を満たしているが、最終的には不十分であることを示す指標として彼を選択しませんでした。各ノードを詳しく見ると、テーブル内のデータの量が特に大きい場合、ツリー全体の高さが上昇し、バイナリツリーノードバランスのみ二人の子供を見つけることができます。指標として二分木バランスレベルの百万のテーブル場合は、多層高いツリーをreaches20う。クエリは、小さなオーバーヘッドではありません20回のディスクIOを行う必要があると、この手段。
だから、そこに大量のデータの場合にすることができ、だけでなく、小さな木、それの高いツリー構造を維持するために？
BツリーとB +ツリー
答えはBツリーです。私たちは、多分岐ツリーと呼ばれているボトルネックがバランスの取れたバイナリツリーノードが2つだけの子ノードを持っており、Bツリー・ノードが高い木々の問題に最適なソリューションですNの子ノードを格納することができている、我々はBツリーのバランスをとることができ、上記と述べました以下に示すように、インデックスツリーとしてB：
ソースネットワーク
指数は依然としてBツリー最適化することができますとしてではなく局所構造で、我々はB +ツリーの最後のを見て、その後、慎重に作業のインデックスのための最終的修飾なぜB +ツリー上のBツリーに基づいて作られたものを改善するB +ツリーを分析します：
ソースネットワーク
絵からは、B +ツリーは高い木々の問題に良い解決策のように、また、複数の木のバランスが悪いと、Bツリーで見ることができます。
改善されたポイント1：
しかし外観は、ノードBストアが両方インデックスツリー、見出すことができる近い、テーブルは、対応するデータを格納し、そしてB +データを格納するツリーの非リーフノードがインデックスを格納するだけでなく、全てのデータがリーフノードに格納されています。
このような改善を行うのはなぜ？私たちは、あなたが知っている計算を行います。
2ツリーの高さを想定し、主キーは、1つのIO A 16Kの操作データを取得することができる、BIGINT型ID、8バイトの長さは、ノード6つのバイトへのポインタ、1Kに記録されたデータのラインのサイズです。
インデックスはB +ツリーである場合には、ルート・ノードは、格納することができる：16K /（6 + 8）= 1170条インデックスポインタを、第一の層、総エネルギーポイント1170 * 1170 = 1368900インデックスポインタに、葉の底層にノード、ノードを使用すると、1170 * 1170 * 16 = 21902400のレコードの合計を保存することができ、16K / 1K = 16件のレコードを格納することができます
非リーフノードがデータを保存するために多くのスペースを使用してのためにBツリー、の場合、インデックスポインタは確かに少ないに保存され、最終的に全体のツリーあなたは多くのデータとして保存し、B +木にしたい場合は、そう、木の高さを高くする必要があります増加ディスクIOに、その結果は、B +ツリーインデックスとしての性能は、Bツリーよりも高いです。
ポイント2改良：
リーフノードポインタとの間の接続は、アクセス効率範囲を改善します。我々は、範囲クエリにしたい場合は、それが簡単に不要なディスクIOの削減、B +ノードの葉の間にポインタが通過することができます。
概要
ここを参照してください、私たちはすでにデフォルトでは、なぜMySQLの一般的なエンジンへと予備知識を持っているB +ツリーインデックスとして使用しますと信じています。限り、我々は一つのことを覚えておいてくださいよう：インデックスは、クエリのパフォーマンスを向上存在IOディスクを削減することです。
最後に、なぜ一般的に配列とハッシュテーブルへのインデックスとして使用するために応答しません
高効率のハッシュテーブルクエリもののん問い合わせの会社の業務範囲ではない単一の値が、問い合わせのほとんど範囲、？
アレイと効率的なクエリが、しかし、レコードは、インデックスを追跡する必要があるため、低効率を追加および削除は、記録的な低効率を追加したり、削除した大量のデータの場合の結果、時間のメンテナンスや削除を増加させました。