「ハッシュ」の上限として特定のサイズを選択することでクエリのパフォーマンスをチューニングできます。ハッシュ・キーは、インデックス付けされたカラムの実際の値を表します。インデックスのハッシュの目的は、インデックスされた値を特定するためのローの検索、ロード、アンパックという負荷の高い処理を避けることです。必要なだけの実際のロー・データを 1 つのロー ID に含めることで、これらの処理を回避します。

ロー ID を使用することで、Ultra Light がデータベース・ファイル内の実際のロー・データを見つけることができます。ハッシュ・サイズを 0 に設定する (インデックスのハッシュを無効にする) と、インデックス・エントリにはこのロー ID だけが含まれます。ハッシュ・サイズを 0 以外の値に設定すると、ハッシュ・キーも使用されます。ハッシュ・キーには、そのローの変換されたデータすべてまたはその一部を含めることが可能であり、ロー ID とともにインデックスのページに格納されます。

ハッシュ・キーに含まれるロー・データの量は、次の要素によって決まります。

ハッシュの例

インデックスのハッシュの値は、インデックス付けされたカラムの実際のロー・データの順序を保持しています。たとえば、Employees テーブルの LastName カラムにインデックスを作成した場合、4 つの名前が次の順序で表示されます。

Anders

Anderseck

Andersen

Anderson

最初の 6 文字をハッシュした場合、これらのロー値のハッシュ・キーは次のようになります。

Anders

Anders

Anders

Anders

これらのエントリは同じに見えますが、リストの最初の Anders は実際のロー値 Anders を表すために使用されます。リストの最後の Anders は実際のロー値 Anderson を表すために使用されます。

ここで、次の文を考えてみます。

SELECT * 
FROM Employees
WHERE LastName = 'Andersen';

Employees テーブルに Andersen に似た名前ばかりが数多く含まれている場合、ハッシュ・キーではパフォーマンスが向上するほどの一意性がありません。この場合、Ultra Light はこの文の条件に実際に一致するハッシュ・キーを決定できません。インデックスのハッシュ・キーの重複があると、Ultra Light が次の処理を行う必要が生じます。

パフォーマンスが向上するのは、Ultra Light が適正な数のユニークなハッシュを認識可能であり、クエリ条件の評価がそのままインデックス自体につながる場合のみです。たとえば、Employees テーブルに何千という名前があっても、6 文字によるハッシュで十分なパフォーマンス向上が得られます。ただし、Employees テーブルに Anders* で始まる名前が突出して含まれている場合は、少なくとも 7 文字でハッシュして、ユニークなキーの程度を向上させる必要があります。これにより、この例の冒頭に挙げた 4 つの名前は、次のハッシュ・キーで表されるようになります。

Anders

Anderse

Anderse

Anderso

これにより、4 つローの値のうち、アンパックして評価する必要があるのが、4 つではなく 2 つになります。

参照

• Ultra Light max_hash_size 作成パラメータ
• 最適なハッシュ・サイズの選択
• Ultra Light のパフォーマンスと最適化
• Ultra Light インデックスの追加