MySQLデータベースのストレージ構造
Bツリーおよびハッシュインデックスとの間の差
B-treeインデックス
インデックスは、そのように、B-treeインデックスによれば、注文データを直接返すことができ、順に記憶されているが、このデータはインデックス列に含まれる唯一の情報です。このように、シーケンシャルI / O
に適用されます：
完全に一致
レンジマッチング
左端の一致
Hash索引
ハッシュインデックス列の値+データ行ポインタ：したがって、必要がランダムIで得られたデータに応じてポインタを見つけるために検索する/ O
- 適し：
- 完全に一致
適していません。
- ファジーマッチング
- レンジマッチング
- ソートされていません
他の人の抜粋要約：
1、ハッシュインデックスを満たすのみ「=」、「IN」と「<=>」クエリ、クエリが使用できない範囲
ハッシュインデックスの比較は操作の後、多くの場合、ハッシュハッシュ値であるので、それが唯一の検出範囲に基づいて、同等のフィルタリングすることができ、なぜなら、治療後のハッシュアルゴリズムのハッシュ値との大小関係を、その前処理を保証するものではないことはできません対応関係ハッシュサイズ。
図2は、ハッシュインデックスは、操作データ分類のために使用することができません
インデックスに格納されたハッシュは、ハッシュ値の後に計算され、データベースが索引ソート操作のハッシュ値を使用することができないので、ハッシュ値の大小関係は、必ずしも以前のハッシュと同じではないからです。
図3は、インデックスの組み合わせのために、インデックスは、ハッシュ値のハッシュのハッシュ値を計算する際に計算され、次いで、インデックスキーの組み合わせではなく、単一組み合わせます
1つまたは複合インデックスキーのいくつかの前面からハッシュ値、クエリインデックスを計算する際、インデックスハッシュを利用することができません。
性能はBツリー4屈折率よりも必ずしも高い、ハッシュインデックスは、大きなハッシュ値が等しい遭遇しないであろう。
あなたは、インデックスのハッシュを作成した場合、比較的低い選択のインデックスキーについては、その後、ハッシュ値に関連付けられたポインタ情報に格納されているレコードの数が多いでしょう。非常に面倒になりますログのいずれかを突き止めるためにこのように、貧しい全体的なパフォーマンスが得られ、表データに多くの訪問を浪費することになります。
概要：ハッシュがピンポイント小規模、大規模に適用され、列のデータをソートする必要はありません、ないあいまいクエリ、有用な範囲クエリ