「ハッシュ」の上限として特定のサイズを選択することでクエリのパフォーマンスをチューニングできます。ハッシュ・キーは、インデックス付けされたカラムの実際の値を表します。インデックスのハッシュの目的は、インデックスされた値を特定するためのローの検索、ロード、アンパックという負荷の高い処理を避けることです。必要なだけの実際のロー・データを 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 が次の処理を行う必要が生じます。
目的のロー ID に一致するテーブル・ローを探す。
データをロードしてアンパックし、値を評価する。
パフォーマンスが向上するのは、Ultra Light が適正な数のユニークなハッシュを認識可能であり、クエリ条件の評価がそのままインデックス自体につながる場合のみです。たとえば、Employees テーブルに何千という名前があっても、6 文字によるハッシュで十分なパフォーマンス向上が得られます。ただし、Employees テーブルに Anders* で始まる名前が突出して含まれている場合は、少なくとも 7 文字でハッシュして、ユニークなキーの程度を向上させる必要があります。これにより、この例の冒頭に挙げた 4 つの名前は、次のハッシュ・キーで表されるようになります。
Anders
Anderse
Anderse
Anderso
これにより、4 つローの値のうち、アンパックして評価する必要があるのが、4 つではなく 2 つになります。
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |