私はB +ツリーとBツリーを研究しています。誰かが私にそれを明確にすることができれば、私はそれについて2つのことを理解したいと思います。
B +ツリーインデックスにさらに多くの検索キーを保存できるのはなぜですか?私の推測では、その理由は、B +ツリーのノードがデータではなくサブツリーを指しているためだと思います。
B +ツリーインデックスで機能しないデータの比較のタイプはありますか、またはそれらすべてを使用できますか(=、> =、!=、<、<> ...)?
Bツリーの 元の説明 では、内部ノードはインデックスキーだけでなく、テーブルのすべての列を保持していました。 B +ツリーでは、リーフノードのみがすべての列の値を格納します。ツリー内の各ノードは固定サイズであるため、内部ノードから非キーデータを削除すると、より多くのキーを保持するためのスペースが解放されます。
すべての演算子は、BTree/B + Tree構造で動作するように作成できます。一部は他よりも効率的であるため、実際には、非効率的な演算子の1つが関係している場合、クエリオプティマイザはインデックスを使用しないことを選択する場合があります。
最良のケースは平等(=)です。ここでは、一致するキー間隔をルートからリーフまでたどることができ、対応する行が返されます。ルートノードだけから、クエリが空のセットを返すことを決定して、ツリーウォーキングをその時点で停止できるようにすることも可能です。
範囲クエリ(<=、> =)は効率的です。与えられた述語値に対して、ツリーを葉まで歩くことができます。リーフページが二重にリンクされたリストである場合、範囲の残りの部分は、これらのリーフからリーフへのリンクをたどることによって見つけることができます。
ワイルドカード検索では、ワイルドカード文字の場所に応じてツリーを使用できます。述語の途中または最後にある場合は、読み取られた各値の追加チェックを使用して、範囲クエリと同様に検索を続行できます。述語がワイルドカードで始まる場合、B +ツリーはorderedセットであり、先頭のワイルドカードはその中のどこを示していないため、ツリーは使用できません。開始するための注文。
不等式演算子(!=)は、次の2つの範囲条件として扱うことができます。(value < predicate) or (value > predicate)
。データ内の値の分布が非常に偏っている場合でも、ツリーを使用すると効率的である可能性があります。通常の場合、オプティマイザはリーフノードを最初から最後までスキャンする可能性が高くなります。