I have a table and I am creating non-clustered indexes on fields which are used frequently in search in where clause. I am creating indexes using include clause and put all fields inside that.
Ex:
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]
)
As against just creating indexes. These fields are all used in Select. Just wanted to know am I doing it wrong? I get huge performance bonus when I do it like this. If this is okay, then why did Microsoft not use it as default option and include all fields of table in include?
Yes. In general, in SQL, it is always bad to have one pattern – a LOT depends on the usage and that will vary.
In the above case this may or may not be wise or needed or beneficial. Do NOT forget you pay a price – in disc size (=IO and more RAM usage) as well as in update and insert speed (slower).
Generally, INCLUDE should be used cautiously. Start without, then use it where you have problems and it helps.