March 26, 2009 at 11:09 pm
Dear All,
Can anyone give me basic guidelines on creating Indexes...pls.
Thanks in advance.
March 27, 2009 at 6:05 am
That's a very broad topic. Here are a few of my personal pointers
1) Pick the clustered index first and pick it carefully
2) Keep the clustered index as narrow as practical (note: not as narrow as possible, narrow means smaller data types and fewer columns)
3) Usually the most frequently accessed data path is the best place for the clustered index since that's where the data is stored.
4) Create nonclustered indexes only when you know you need them. Create as few as possible and keep them as narrow as practical too.
5) Test, test, test, test, test, test
6) Test some more.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 27, 2009 at 7:12 am
swmsan (3/26/2009)
Dear All,Can anyone give me basic guidelines on creating Indexes...pls.
Thanks in advance.
Let me give a shot too:
1.) There should be atleast one clustered index for a table which should be Narrow, ever-increasing, unique
2.) Try think of creating clustered indexes on the ones which are used in range queries and the ones which are used for ORDER by clause
3.) Frequently updated columns and non-unique columns are not a good choice
4.) Non- clustered indexes when needed but be careful about the number of indexes . more number of indexes more performance overhead on your table for DML operations
5.)Think about Covering indexes to cover all the columns retrieved in your query
6.) Order of Index columns pretty important as SQL server maintains indexes only on the lading edge of the indexed columns
7.) Give consideration about fill factor too when creating indexes, inappropriate fill factor may lead to index fragmentation
March 27, 2009 at 2:05 pm
Krishna (3/27/2009)
1.) There should be at least one clustered index for a table which should be Narrow, ever-increasing, unique
At least one?
5.)Think about Covering indexes to cover all the columns retrieved in your query
Not all queries can be covered, not all queries should be covered. Sometimes the cons outweigh the pros. (Think of the size of a very large covering index)
6.) Order of Index columns pretty important as SQL server maintains indexes only on the lading edge of the indexed columns
I assume you mean statistics on the leading column?
There's a lot, lot more to order of columns that that. I wrote two blog posts on just that topic
http://sqlinthewild.co.za/index.php/2009/01/19/index-columns-selectivity-and-equality-predicates/
http://sqlinthewild.co.za/index.php/2009/02/06/index-columns-selectivity-and-inequality-predicates/
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
March 27, 2009 at 2:13 pm
GilaMonster (3/27/2009)
Krishna (3/27/2009)
1.) There should be at least one clustered index for a table which should be Narrow, ever-increasing, uniqueAt least one?
OMG what am I saying- only one
5.)Think about Covering indexes to cover all the columns retrieved in your query
Not all queries can be covered, not all queries should be covered. Sometimes the cons outweigh the pros. (Think of the size of a very large covering index)
Definitely not there are cons as well, but gave a basic idea
6.) Order of Index columns pretty important as SQL server maintains indexes only on the lading edge of the indexed columns
I assume you mean statistics on the leading column?
yes, ahh may be am smoking something when i was typing. 🙂
thanks for pointing it out. next time should be careful while typing.....
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply