3

次の表がありますReportType。このテーブルには100行程度しかなく、アプリケーションによって更新されることはありません（つまり、INSERTパフォーマンスは問題になりません）。UPDATEDELETE

Table: ReportType
===========================================================
|  ID (PK)  |  Name  |  ExportFormat  |  SourceDatabase   |
===========================================================

非クラスター化インデックスを設定する価値はありExportFormatますか？この列は、一部のシナリオおよび一部のレポートでフィルター基準として使用されます。選択性はまったく高くなく（おそらく10個の異なる値しかない）、クラスター化されていないインデックスの適切な候補にはならないことを示しています。しかし、このテーブルINSERTで操作が発生することはUPDATEないDELETEので、インデックスが実際にここで役立つのは確かです（ほんの少しでも）。

4

2 に答える 2

3

経験則として、128 行未満のテーブルにインデックスを作成すると、必要以上のオーバーヘッドが追加されます。特に非クラスタ化インデックスの場合、1 回のブックマーク ルックアップは、テーブル全体をスキャンするよりも広範囲に及ぶ可能性があります。

于 2013-01-16T14:33:57.350 に答える
2

あなたが受け入れた答えには同意しません。

このテーブルは読み取り専用であると言うので、以下のように非クラスター化インデックスをカバーすることのマイナス面はわかりません。

CREATE NONCLUSTERED INDEX IX 
     ON  ReportType(ExportFormat) INCLUDE(ID,Name,SourceDatabase )

このような少量の行の場合、メリットはごくわずかですが、クエリ フィルタリングごとにすべての行を処理する必要がなくなります。ExportFormat

于 2013-01-16T15:28:11.997 に答える