2

テーブルがあり、where句の検索で頻繁に使用されるフィールドに非クラスター化インデックスを作成しています。include句を使用してインデックスを作成し、その中にすべてのフィールドを配置しています。

元：

Create NonClustered Index IX_DocumentDate on Documents
(
    DocumentDate     
)
Include(
    JurisdictionID,
    JudgementTypeID,
    IDate,
    EfileDate,
    UserID,
    RecordingDateTime,
    ApprovedBy,
    ACEfileBankAccountID,
    LastStatusChangedDateTime,
    ACEfileCreditCardID,
    EfiledByUserID,
    ITypeID,
    IGroupID,
    InstrumentID,
    OldInstrumentID,
    [CreatedByJurisdictionID],
    CreatedByAccountID,
    [DocumentStatusID]      
      ,[Remarks]
      ,[InternalNotes]
      ,[ParentDocumentID]
      ,[FilingNumber]
      ,[StampData]      
      ,[Receipt]
      ,[ReceiptNo]
      ,[IsReEfiled]      
      ,[ImportedFromInstrumentID]
)

インデックスを作成するだけではありません。これらのフィールドはすべてで使用されSelectます。私が間違っているのか知りたかっただけですか？このようにすると、大きなパフォーマンスボーナスが得られます。これで問題がない場合、なぜMicrosoftはこれをデフォルトのオプションとして使用せず、テーブルのすべてのフィールドをに含めなかったのincludeでしょうか。

4

3 に答える 3

5

はい。一般に、SQLでは、1つのパターンを持つことは常に悪いことです。LOTは使用法によって異なり、それは異なります。

上記の場合、これは賢明であるか、必要であるか、または有益である場合とそうでない場合があります。ディスクサイズ（= IOおよびより多くのRAM使用量）と更新および挿入速度（遅い）で料金を支払うことを忘れないでください。

通常、INCLUDEは慎重に使用する必要があります。なしで始めて、それからあなたが問題を抱えているところでそれを使ってください、そしてそれは助けになります。

于 2012-12-27T06:16:14.730 に答える
3

テーブル全体を2回、1回はインデックスに、もう1回はメインテーブルに保存しています。これは一般的にスペースの無駄と見なされます。また、インデックスの効率も低下します。含まれる列がない、または含まれる列が少ない場合よりも、読み取るデータが多くなります。インデックスにプライマリドキュメントID列を含めることは賢明かもしれませんが（どの列がプライマリドキュメントIDであるかは明確ではありませんが）、含めた列の大部分は明らかにインデックスに不要です。

したがって、デフォルトの動作ではない理由は、列が含まれていないインデックスほど効率的ではないためです。したがって、必要になるまでインデックスに列を含めないでください。そうすることで、パフォーマンスが向上することを測定できます。

于 2012-12-27T06:27:40.417 に答える
0

1つの列に対してクラスター化インデックスを試すことができます。主キーを使用して、パフォーマンスを確認することもできます。クラスタ化インデックスのパフォーマンスを、すべての列のインデックスと比較できます。ベストプラクティスでは、要件ごとに最小のインデックスを設定する必要があります。

于 2012-12-27T10:38:04.657 に答える