Usually the clustered index is created in SQL Server Management Studio by setting the primary key, however my recent question about PK <-> clustered index (Meaning of Primary Key to Microsoft SQL Server 2008) has shown that it is not necessary to set PK and clustered index to be equal.
So how should we choose clustered indexes then? Let's have the following example:
create table Customers (ID int, ...)
create table Orders (ID int, CustomerID int)
We would usually create the PK/CI on both ID columns but I thought about creating it for Orders in CustomerID. Is that the best choice?
You cannot alter a clustered index. The only option is to drop it and re-create it with the new column. In your case, you'll probably have to re-create the table with the new clustered index on ID and then copy the data over.
As a guideline, clustered Indexes should be Narrow, Unique, Static and Ever Increasing (NUSE).
According to The Queen Of Indexing - Kimberly Tripp - what she looks for in a clustered index is primarily:
And if you can also guarantee:
then you're pretty close to having your ideal clustering key!
Check out her entire blog post here, and another really interesting one about clustering key impacts on table operations here: The Clustered Index Debate Continues.
Anything like an INT (esp. an INT IDENTITY) or possibly an INT and a DATETIME are ideal candiates. For other reasons, GUID's aren't good candidates at all - so you might have a GUID as your PK, but don't cluster your table on it - it'll be fragmented beyond recognition and performance will suffer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With