nvarchar(n) 列を SQL Server データベースのクラスター化インデックスとして使用すると、数値 (int) インデックスと比較してパフォーマンスが大幅に低下しますか? また、複合インデックスのパフォーマンスはどのように比較されますか?
4031 次
5 に答える
8
Sql は、インデックスが数値であるかどうかを気にしませんが、列の内容とテーブルの使用方法に応じて、考慮する必要があることがいくつかあります。
一般に、インデックスをできるだけ小さく保ちたいので、nvarchar(4000) (最大 8000 バイト) は本当にひどいですが、varchar(3) (最大 3 バイト) は int (4 バイト) よりも小さくなります。また、(可能な場合) インデックス挿入をインデックスの最後に挿入することで、インデックスが断片化してパフォーマンスの問題が発生するのを防ぎます。
テーブルに対して実行しているクエリにインデックス内の列のみが含まれている場合、複合インデックスを使用するとパフォーマンスが大幅に向上します。これは、インデックスがクエリを満たすため、実際のテーブルに触れることさえないことを意味します。
インデックスの概要については、SQL サーバー インデックスの基本を参照してください。
テーブル自体とそれをどのように使用したいかについて、より具体的な詳細を提供していただけると、より役立つかもしれません。
于 2009-05-22T14:08:59.260 に答える
2
コリン、
nvarchar は、varchar 列の 2 倍のスペースを使用します。nvarchar 列がテーブルの唯一のインデックスである場合、ヒットはそれほど大きくない可能性がありますが、そのテーブルにもクラスター化されていないインデックスがある場合は、パフォーマンスが低下します。これは、クラスター化インデックスが非クラスター化インデックスのすべての行にも含まれており、非クラスター化インデックスが非常に広くなるためです。一方、int 列は 4 バイトしか占有せず、-2,147,483,648 から 2,147,483,647 までの値を格納する範囲が大きく、狭い傾向にあります。4 バイトの場合、nvarchar 列は、varchar(2) 列の 2 倍のスペースを使用するため、最大でも varchar(2) で使用されるスペースしか格納できません。どれだけのスペースを無駄にしているかわかりますか?
于 2009-05-22T14:12:32.280 に答える
1
ほぼ間違いなくそうです。
狭く、数値的で厳密に単調なキーは、適切なクラスター化されたキーになります。nvarchar はこれらのどれでもありません。
クラスター化されていない各インデックス エントリはクラスター化インデックスを参照するため、NC インデックスも肥大化します。
これは、照合/比較の問題の前です。
于 2009-05-22T14:09:56.857 に答える
0
テーブルの大きさにもよると思います。小さいテーブルの場合、違いに気付くとは思えませんが、たとえば 100 万行以上の大きなテーブルでは、nvarchar を使用するとわずかに速度が低下することがあります。フィールドに実際に何が含まれているかにも依存していると思います..つまり、電子メールなどです.
于 2009-05-22T14:10:51.050 に答える
0
インデックスについて話すときは、「パフォーマンス」を 2 つのトピックに分ける必要があります。
挿入、更新、および削除時に、インデックスはデータベースの速度を低下させます。基になるデータストアでデータを移動する必要がある場合があるため、クラスター化されていないインデックスよりもクラスター化されたインデックスの方が速度が低下します。ここで、シーケンシャル int の方が nvarchar よりもパフォーマンスが優れているという John の意見に同意します。
ただし、とにかく nvarchar フィールドに対してクエリを実行する必要がある場合は、このフィールドのクラスター化インデックスを使用すると、読み取りを高速化できます。
したがって、あなたの質問への答えは、挿入または読み取りのパフォーマンスを心配しているかどうかによって異なります。
于 2009-05-22T14:33:34.453 に答える