クラスタ化されていないインデックスを1000行未満のテーブルに追加すると、頻繁にアクセスするとパフォーマンスが向上しますか？

Question

私はちょうど400-500行のテーブルを持っていますが、このテーブルは非常に頻繁にアクセスされていますので、その列の1つに非クラスタ化インデックスを追加して改善が必要かどうか疑問に思っていましたか？

この表は、常に同じデータを保持し、まれに更新されます。ここで

は、このクラスタ索引付き

CREATE TABLE [dbo].[tbl_TimeZones](
    [country] [char](2) NOT NULL, 
    [region] [char](2) NULL, 
    [timezone] [varchar](50) NOT NULL 
) ON [PRIMARY] 

テーブルの構造です：

CREATE CLUSTERED INDEX [IX_tbl_TimeZones] ON [dbo].[tbl_TimeZones] 
(
    [country] ASC, 
    [region] ASC, 
    [timezone] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
GO 

領域列がヌル可能性があるため、この表に主キーを持っていませんなぜそれがです私はまだ鍵を使っていない。

したがって、パフォーマンスを向上させるために、タイムゾーンに非クラスタインデックスを追加したいとします。

Answer 1

短い回答：インデックスはおそらくあなたのパフォーマンスを向上させます。

レコード数だけでも、よく選択されたインデックスでクエリの改善が見られます。この表が結合で使用されていると仮定すると、その表を介して結合する問合せ計画の変更（改善）が見えて、予想以上に大きな利点が得られる可能性があります。

「1つの」列のインデックスを作成すると思われるようです。おそらく1つの列のインデックス作成は最適な解決策ではありません。 「カバリング」インデックスは、一般的に、より良い解決策になります（Googleでは「カバリングインデックス」）。

ここまでで、クラスタリングされたインデックスがどのように定義されているかによって最高のパフォーマンスが得られると思われます。この表のクラスタード・インデックスの性質、またはデータの使用を指定していません。ただし、クエリがほとんど常に同じ方法でテーブルにアクセスする場合（WHERE句とJOIN句は常に同じ列を参照します）、クラスタ化インデックスを変更すると最も改善されます。

また、インデックスを選択する技術の一部では、クエリのパフォーマンスと挿入/更新のパフォーマンスのバランスが取られています。データが変化していなければ、その挑戦はありません。一般的なインデックスチューニングのアドバイスを読むときは、それを覚えておいてください。

結論：WHERE句とJOIN句で使用されている列に対するクラスタ化インデックスが答えと思われます。列の順序の問題を考慮する。選択性は重要です。