-
インデックスがないと、データベースエンジンは、ディスクIOを大量に生産する全表スキャンによってデータを見つける必要があります。
-
クエリをスピードアップするためにB +ツリー索引を使用してリレーショナルデータベース。B +ツリーは二分探索木である（各ノードはキーでなければならない：任意のキーは右のサブツリーに格納されている任意のキー値よりも小さくなるように、サブツリーを保存より大きい左）ので、ランダム探しキーは、ルートノードからバイナリ検索クエリを実行することによって加速することができる場合には、層の数は、クエリツリーのコストに依存します。
-
範囲クエリの最適化をソート：クエリの範囲は葉の裏を横断した後、左側の値の範囲からそのリーフ・ノードを見つけるために、ルートノードから始めて、範囲を指定したので、各リーフノードで次のリーフノードへのポインタ、保存権利範囲クエリを加速することができる対応する範囲値を見つけるためにノード、ソート、グループ化、および他のデータベースクエリ操作。
-
ディスクの読み取りおよび書き込み速度を最適化するための単一のディスクを読み取ることができるので、唯一のキー保存リーフノードを除いて、他のノードを書き込み多くのデータとして取得します。MySQLのために、例えば、B +ツリーの千万ラインがマスターキーに基づいて理論的に見つけるためのテーブルに対応するだけで三回全表スキャンより多くのディスクIO性能のオーダーであると比べもたらしたディスクIOを、必要とします。
-
MySQLとB +ツリーインデックスの実際の実装時の他のデータベースエンジンは、ディスクの読み取りと書き込みのために最適化された非リーフノードは、異なる記憶データを区別する主な指標に応じて、データを格納するリーフノードのキー値に加えて、唯一のキー値を格納しますインデックス（クラスタ化インデックス）とセカンダリインデックス：
リーフノードA）主記憶キーに対応するインデックス値の完全な記録を見つけるために、一次インデックスを使用し、直接出力記録することができる。テーブルはプライマリインデックスを作成することができます。
メインインデックス・ルックアップを次にリーフノードB）一般的な指標は、主キー値に対応する格納され、そのため二次インデックスが見つけるためとき、主キーを見つけることが必要であり、かつ、二次インデックステーブルを複数作成することができます。
-
リレーショナルデータベースは、一般的にハッシュインデックスをサポートするB +ツリーに加えて、ハッシュインデックスは非常に効率的なランダム検索することができますが、範囲クエリのために、並べ替えやグループ化がサポートされていません。
