2

行の特定のサブセットが読み取りに対してはるかに高温であるテーブルがあるとします。テーブルis_aliveを要求するフラグがある場合のように。peopleまたは、ソフト/論理削除を実装し、検索条件に常にが含まれている場合is_deleted = 0。

これらのフィールドは、これらのテーブルのインデックスに含める必要がありますか？もしそうなら、彼らはもっと左にすべきですか、それとももっと右にすべきですか？

次のようなインデックスがあるとしましょう...

people [ last_name ]
people [ zip_code ]
people [ gender ]

widgets [ category_id ]
widgets [ seller_id ]

あなたはそれらを次のように見せますか

people  [ last_name, is_alive   ]
widgets [ category_id, is_valid ]

または

people  [ is_alive, last_name   ]
widgets [ is_valid, category_id ]

ブール値自体は、他の検索条件と組み合わせない限り、カーディナリティ/重要度が低くなります。

このフィールドはほぼ毎回使用されますが、すべてのインデックスにこのフィールドを追加するのは怪しいと感じます。たぶんそれ自体が「問題」なのだろうか？同じスキーマを持つ別のテーブルに行をシャトルする必要がありますか？基本的にフラグで分割します。

ベンダーにとらわれない。

4

2 に答える 2

1

インデックスがクエリに役立つ主な方法の 1 つは、全テーブル スキャンで読み取る必要があるページ数を減らすことです。データベース エンジンがページを管理していることを思い出してください。ページにはレコードが格納されます。顧客のテーブルがあり、状態のインデックスがあるとします。単一の状態に絞り込むクエリは、ごく一部のデータのみを読み取る必要があります。もちろん、その割合は 10% (カリフォルニア州) であるのに対し、小さな州では 1% 未満になる可能性があります。問題は、このデータを読み取るのに何ページ必要かということです。

この質問に答えるには、情報が必要です: (1) クエリはどの程度選択的ですか? (2) 1 ページに収まるレコードの数は? したがって、100 レコードが 1 ページに収まる場合、行の 2% を選択するクエリは、ほとんどの場合、とにかくすべてのページを読み取る必要があります。この場合、インデックスは完全なテーブル スキャンをサポートしていません。インデックスはオーバーヘッドが発生するため、おそらく使用しないでください。

一方、ページに収まるレコードが 1 つだけの場合、行の 2% を選択するクエリは、ページの 2% を読み取るだけで済み、50 倍の節約になります。インデックスによって発生するほとんどのオーバーヘッドは、それだけの価値があります。

インデックスは複数の目的で使用され、データベース エンジンによって実装方法が異なり、ページ テーブルの実装方法も異なるため、厳格なルールはありません。ただし、カーディナリティの低いフラグは、おそらくインデックスの候補として適していないと言えます。

考えてみると、インデックスが効率的であると思われるケースが 1 つ思いつきます。これは、幅の広い行と、インデックスによって排他的に処理できるクエリ (select フラグ、count(*) from table group by フラグ) の場合です。

一方、そのようなフラグが複数ある場合は、複合インデックスがクエリのパフォーマンスを向上させる可能性があります。

于 2012-05-09T18:08:42.113 に答える
0

一部の RBDMS では、SQL Server 2000 などのビット フィールドにインデックスを配置することさえできません...

ただし、ベンダーにとらわれない必要があります...通常、その有用性を決定するのはインデックスの選択性です。

にインデックスがis_aliveあり、分割が 50% 有効 / 50% 無効である場合、そのインデックスは有用であるほど選択的ではありません。

ただし、分割が 99% 生存、1% 死亡のようなものである場合は、死亡者を検索するときにインデックスを使用できますが、生存者を検索するときは無視されます。

そのため、フィールドに特定の値を持つ行の割合が少なく、その特定の値を持つ行を頻繁に検索して、インデックスのメンテナンスのオーバーヘッドを正当化する場合、インデックスが役立つ場合があります。

ただし、これは使用している RDBMS に完全に依存することに注意してください。その特定の RDBMS に対してパフォーマンス関連の設計上の考慮事項をテストする必要があります。

于 2012-05-09T18:08:25.140 に答える