0

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

region 列がnullになる可能性があるため、このテーブルには主キーがありません。そのため、まだキーを使用していません。

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

4

1 に答える 1

1

簡単な答え: インデックスを使用すると、パフォーマンスが向上する可能性があります。

より長い答え。それだけの数のレコードでも、適切に選択されたインデックスによってクエリの改善が見られます。このテーブルが結合で使用されると仮定すると、そのテーブルを介して結合するクエリ プランに変更 (改善) が見られる可能性があり、予想以上に大きなメリットが得られる可能性があります。

「1つの」列にインデックスを付けることを期待しているという印象を与えているようです。1 つの列だけにインデックスを付けることは、おそらく最適なソリューションではありません。一般的には、「カバーする」インデックスの方が優れたソリューションになります (Google は「カバーするインデックス」を意味します)。

以上のことから、最高のパフォーマンスはクラスター化インデックスの定義方法から得られるのではないかと思います。このテーブルのクラスター化インデックスの性質、またはデータの使用については示されていません。ただし、ほとんどの場合、クエリが同じ方法でテーブルにアクセスする場合 (たとえば、WHERE 句と JOIN 句が常に同じ列を参照する場合)、クラスター化インデックスを変更すると最も改善されることがあります。

また、インデックスを選択する技術の一部には、クエリのパフォーマンスと挿入/更新のパフォーマンスのバランスを取ることが含まれます。データが変更されていない場合、その課題はありません。一般的なインデックス調整のアドバイスを読むときは、このことを念頭に置いてください。

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

于 2011-12-17T03:05:41.427 に答える