SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Stairway to SQL Server Indexes: Level 15, Indexing Best Practices


Stairway to SQL Server Indexes: Level 15, Indexing Best Practices

Author
Message
David Durant
David Durant
Mr or Mrs. 500
Mr or Mrs. 500 (540 reputation)Mr or Mrs. 500 (540 reputation)Mr or Mrs. 500 (540 reputation)Mr or Mrs. 500 (540 reputation)Mr or Mrs. 500 (540 reputation)Mr or Mrs. 500 (540 reputation)Mr or Mrs. 500 (540 reputation)Mr or Mrs. 500 (540 reputation)

Group: General Forum Members
Points: 540 Visits: 23
Comments posted to this topic are about the item Stairway to SQL Server Indexes: Level 15, Indexing Best Practices
Ognjen Kovacevic
Ognjen Kovacevic
SSC-Enthusiastic
SSC-Enthusiastic (188 reputation)SSC-Enthusiastic (188 reputation)SSC-Enthusiastic (188 reputation)SSC-Enthusiastic (188 reputation)SSC-Enthusiastic (188 reputation)SSC-Enthusiastic (188 reputation)SSC-Enthusiastic (188 reputation)SSC-Enthusiastic (188 reputation)

Group: General Forum Members
Points: 188 Visits: 608
You repeat explanation of "Consider Using a Foreign Key in the Search Key of the Clustered Index" in "Consider Having Included Columns in your Indexes " ;-)
Rasmus Remmer Bielidt
Rasmus Remmer Bielidt
Ten Centuries
Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)

Group: General Forum Members
Points: 1002 Visits: 144
Thanks for putting the effort into writing this complete guide. It's made a lot of things and issues a lot more clear to me.
jthalliens2004
jthalliens2004
SSC Rookie
SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)

Group: General Forum Members
Points: 30 Visits: 71
all the articles were amazing i got a better idea on how to implement indexes using best practices
MadAdmin
MadAdmin
SSCertifiable
SSCertifiable (5.5K reputation)SSCertifiable (5.5K reputation)SSCertifiable (5.5K reputation)SSCertifiable (5.5K reputation)SSCertifiable (5.5K reputation)SSCertifiable (5.5K reputation)SSCertifiable (5.5K reputation)SSCertifiable (5.5K reputation)

Group: General Forum Members
Points: 5523 Visits: 2005
My reason for creating a clustered index on RID is that
Where using the non clustered index for joins or queries, if the RID was an output of the query or join, then it will be satisfied by an index seek or scan without having to do an RID lookup, hence behaving like an included index.
Else, you will be hit with RID lookup, if table is a heap.
Execution plans also become easier to optimise [seek plus lookup becomes only seek]so SQL can make a better choice of what to do.

Secondly a scan of RID is faster than if it was a scan of nonclustered index, in the cases where scans are unavoidable, 64k reads on clustered index pages vs (8k reads and jumping between non clustered index and Table).

Catch-all queries done right
Gail Shaw's Performance Blog
Ray Ayyelos
Ray Ayyelos
Valued Member
Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)

Group: General Forum Members
Points: 62 Visits: 110
Two comments:
1) Thanks for writting the series. It is always nice to review information. Being reminded of something useful or learning something new is always a pleasant surprise. I think I was both reminded of something useful and learned something new in this series.

2) In the final segment, your comments for the following sections are identical:
-Consider Using a Foreign Key in the Search Key of the Clustered In
-Consider Having Included Columns in your Indexes
GilaMonster
GilaMonster
SSC Guru
SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)

Group: General Forum Members
Points: 473663 Visits: 47381
One guideline I strongly disagree with...

Avoid Nonclustered, Unfiltered Indexes on Columns that have few Distinct Values
The old cliché is “Never index the Gender column”. A typical page of the table will have half female rows and half male rows, and will be accessed whether the request is for female rows or for male rows. A table scan will always be the best decision for any WHERE GENDER = … query; therefore, such an index will never be of benefit to the optimizer.


Not at all. While an index on just the Gender column may not be very useful, an index that starts with the gender column, perhaps has other key columns and maybe an include column or two can be very, very useful indeed, especially if you have a lot of queries that filter on gender and ...

A table scan will not always be the best decision for a filter on a high density column (high density = not very unique). If the index on the column is covering, seeks can and will be used even up to cases where 100% of the rows in the table affected by the query.

Also
Consider Using a Foreign Key in the Search Key of the Clustered Index


Maybe, but by doing so you're losing the ever-increasing attribute that is suggested for clustered indexes and maybe (depending what the other key columns are and if the foreign key every changes) the narrow, unchanging and unique as well

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


gil 17845
gil 17845
SSC Rookie
SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)

Group: General Forum Members
Points: 44 Visits: 18
Thanks for very clear overview of indexing considerations. A related topic that is sometimes overlook is the challenge of predicting the effects of an individual index on the workload as a whole. A recent article by Ami Levin, The Hidden Menace of CREATE INDEX, highlights this issue with some vivid examples. Worth a read.
bwilliams-1049831
bwilliams-1049831
SSC-Enthusiastic
SSC-Enthusiastic (190 reputation)SSC-Enthusiastic (190 reputation)SSC-Enthusiastic (190 reputation)SSC-Enthusiastic (190 reputation)SSC-Enthusiastic (190 reputation)SSC-Enthusiastic (190 reputation)SSC-Enthusiastic (190 reputation)SSC-Enthusiastic (190 reputation)

Group: General Forum Members
Points: 190 Visits: 210
In the Indexing best practices
Here is another avoid

Avoid using fields in indexes that are updated frequently.
Status fields are a prime example. Each time the field is updated the index has to be updated.
This is a major cause of deadlocking on the index structures of one application where I am currently employed and has caused me endless grief.
There are 6 different statuses as the record proceeds through our system and a dashboard watches it real time from created, validated, ready, processing, sent, complete. Each time causes the index to be updated as well.
GilaMonster
GilaMonster
SSC Guru
SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)SSC Guru (473K reputation)

Group: General Forum Members
Points: 473663 Visits: 47381
bwilliams-1049831 (3/28/2012)

Avoid using fields in indexes that are updated frequently.
Status fields are a prime example. Each time the field is updated the index has to be updated.


Maybe. Depends on how often that field is filtered on, how important the queries that filter on it are, etc. It's a tradeoff and has to be evaluated case-by-case. If the status is frequently updated but seldom searched on then an index on it would indeed be a bad thing.

Indexes on frequently changing columns don't automatically cause deadlocks, if you're talking about key lookup deadlocks then the usual way to prevent the deadlocks is to ensure the index is covering (or use one of the row version based isolation levels)

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search