Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Yes, you can only have a single clustered index per table - the data is physically arranged by that index, so you cannot have more than one.</p> <p>I would however not advise to use a composite clustered index. Why? Because the clustered index should always be:</p> <ul> <li>as small as possible - INT with 4 byte is perfect</li> <li>stable - never change, so you don't have rippling updates through all your indices</li> <li>unique - otherwise, SQL Server will have to "uniquify" your entries with artifical 4-byte values</li> <li>optimal would be: ever increasing</li> </ul> <p>INT IDENTITY is perfect as a clustered index - I would advise you keep it that way.</p> <p>The clustered index column (or set of columns) is also added to each and every entry of each and every nonclustered index on that same table - so if you make your clustered index large, 20, 50 bytes or more, you begin to be wasting a lot of space - on disk and in your server's memory, which generally degrades your system performance.</p> <p>Read all about clustered indices and what they should be to be good clustered indices here:</p> <ul> <li><a href="http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx" rel="noreferrer">GUIDs as PRIMARY KEYs and/or the clustering key</a></li> <li><a href="http://sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-Continues.aspx" rel="noreferrer">The Clustered Index Debate Continues...</a></li> <li><a href="http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx" rel="noreferrer">Ever-increasing clustering key - the Clustered Index Debate..........again!</a></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload