1

Guid によってテーブルをクエリする場合 (Guid の断片化の問題に関係なく)、Guid をクラスター化されていないインデックスとして使用するか、インデックスをまったく使用しないよりも高速でしょうか?

この質問は、読み取り専用の観点からのものです。特定の Guid の検索行間で速度が向上するかどうか、およびインデックスの有無にかかわらず、またはクラスター化インデックスの有無にかかわらず、検索がより高速に完了するかどうかに興味がありますか?

または、次の質問への回答にはかなり確信がありますが、前の質問に int 識別子を適用します。テーブルがそのintでクラスター化されていると、検索が速くなりますか? (これは、テーブル内の他のアイテムによってクラスター化されているのではなく?)




このトピックには他にも多くの質問が投稿されていることは知っていますが、これらのいずれにも探している特定の回答が見つかりませんでした:
Sequential Guid 主キー列はクラスター化インデックスにする必要がありますか?
クラスター インデックス GUID 主キーのパフォーマンスの向上 インデックスを使用した SQL Server のuniqueidentifier
の一意の識別子 ID 列のクラスター化された主キーGuid 列のクラスター化インデックスを削除する必要があります

助けてくれてありがとう！

4

3 に答える 3

3

テーブルは、GUIDインデックスよりも整数クラスター化インデックスの方が確実に高速にクエリを実行します。その理由は、データ型のサイズです。

GUIDをキーとして使用することをすでに決定している場合は、おそらくNewId（）の代わりにnewSequentialId（）を使用してこれらのGUIDを生成します。これにより、Idが常に増加し、ページ分割。

私のポイントに加えて、クラスター化されたインデックスの潜在的な候補がない限り、つまり、このGUIDを主要な目的ではなく使用している場合を除いて、これをクラスター化されたインデックスとして使用するのは自然な選択です。インデックスを持たないという選択肢がある場合の比較的小さなテーブルの場合は、インデックスを付けるのが常に適切です。

于 2010-06-23T14:31:36.573 に答える
2

Assuming MS SQL Server. This may or may not apply to other RDBMSs:

If you have a clustered index then it will be fastest, although if you're searching for a single row then the difference between that and a non-clustered index will be negligible. When you use a non-clustered index the server needs to first find the right value in the index and then go fetch the full record from the table storage. The table storage is the clustered index, so searching by a clustered index eliminates that step (called a Bookmark Lookup), but that step is almost imperceptible for a single row.

Clustered indexes tend to provide a bigger advantage for reading when they are on a column that is selected by range (for example, transaction date and you want to find all transactions for the past month). In that case the server can find the start and just read off the data in one quick, sequential sweep.

Having a non-clustered index on an INT (all other things being equal) will be slightly faster than using a GUID because the index itself will be smaller (because INTs are much smaller than GUIDs) which means that the server has to traverse fewer pages to find the value that it's looking to get. In the case of a clustered index I don't think that you'll see much of a difference if your row sizes are already large compared to the difference between a GUID and an INT, but I haven't done any testing on that.

于 2010-06-23T14:35:18.273 に答える
1

Tom が既に述べたように、クラスター化されたインデックスでの単一要素の検索は、常に高速になります。これは、クラスター化インデックスがデータそのものであり、インデックス エントリを見つけた後にルックアップが必要ないためです。

クラスタ化インデックスの主な利点は、データの「範囲」(「先週」や「日付別の注文履歴」など) を抽出できることです。GUID はテーブル全体に均等に広がる傾向があるため、ここではこの利点を得ることができません。また、各テーブルにはクラスター化インデックスを 1 つしか持てないため、慎重に選択してください。

特定の範囲について最も一般的にテーブルにクエリを実行する場合は、そのテーブルをクラスター化インデックスと見なします。

また、カバリングインデックスと呼ばれる第3種もあります。カバリング インデックスは、最も一般的なクエリを満たすことができる複数のフィールドで構成されます。たとえば、ID、Displayname、Password、LogonDate、..... を持つ USER テーブルがあり、DisplayName が頻繁に必要になります。ID、Displayname に基づいてインデックスを作成すると、次のようなクエリのカバリング インデックスと見なされます。

Select Displayname from USER where ID=XYZ

編集：私が言及するのを忘れていたことが1つあります。GUID は、SQL に関しては非常に大きなオブジェクトです (まあ... 16 バイト)。これをクラスター化インデックスとして使用すると、そのテーブルの他のすべてのインデックスに、GUID への 16 バイト ポインターが強制的に含まれるようになります。そのテーブルに多数のインデックスがある場合、これは合計される可能性があります。クラスター化されたインデックスは、小さくて一意であることが最適です。それがINTがとても素晴らしい理由です。

于 2010-11-17T13:30:56.930 に答える