From MSDN documentation on primary keys and clustered indexes,
PRIMARY KEY constraints create clusteredindexes automatically if no clustered index already exists on the table
http://msdn.microsoft.com/en-us/library/aa933131(v=SQL.80).aspx
What is the reasoning behind creating aclustered index on the primary key by default? Any index would seem to make sense if the attribute is assumed to be queried a lot. Under that assumption, why a clustered index instead of nonclustered index?
From the MSDN documentation onClustered IndexStructures, and
figure 4-16 from
Inside Microsoft SQL Server 2008: T-SQL Querying, it seems as though either 1 leaf or at least 1 page would be allocated in the B-tree for each primary key's record (unlessuniqueclustered indexes are implemented as sparse indexes, but the documentation doesn't say so). The minimum cost to retrieve 1 record for a key value is 1 page,
Disk I/O operations are performed at thepage level. That is, SQL Server reads or writes whole data pages.
http://msdn.microsoft.com/en-us/library/ms190969.aspx
in which case I see no apparent performance advantage over a nonclustered index on a primary key. In either case, whether clustered or nonclustered index, you traverse the B-tree to the leaf level and read 1 page which has the 1 possible data record. So, why is it any faster to query a clustered table for a given primary key value vs. a heap, when either way you're searching a B-tree to find 1 page?
Considering that it costs more to maintain aclustered table than a heap, why create aclustered index on the primary key by default, i.e. why not nonclustered index instead?
Thank you.
T. Webster
