I have heap table with Primary Key composed of 2 columns.
First column of PK is INT and second column is varchar(50).
Currently, this PK is non-clustered index even if by default, sql creates PK as clustered.
Since this PK is 54 byte(or 29 bytes in average), this would enormously enlarge all other non-clustered indexes. So, I agree it is better to have this PK as non-clustered.
Only when this PK would be part of the most of non-clustered index anyway, than it is better to have it as clustered, i guess? I know it depends, but anyway, what is your opinion for some common case?
Since table doesn't have clustered index, sql adds rowID to every non-clustered index row. Row id is 8 byte.
Wouldn't it be better to add some identity column to this table(even if I don't need it anywhere) and mark it as clustered unique index? Than this clustered key, which is only the half of the size of rowID(4 byte), would be added to every non-clustered index
row and every row of non-clustered index this way would have 4 bytes less?
And another benefit is that the table is more likely to be less fragmented if clustered than non-clustered.
And when retrieve data from heap table sql server has to read IAM page first to get the records location and then read the actual data, i.e 2 read to get the data. But in the case of cl index the leaf node contain the row locator and the data, so, only
1 read (when table scan is in progress). So, table scan is usually faster than clustered scan.
So, i guess it is always better to add some extra identity column only to get table clustered than have a heap table.
(if I neglect that special cases when heap is better than clustered, such as staging tables)
But in some cases clustered index on wide PK would benefit more than adding additional identity column only for clustered purpose(or having a heap table). Which are this cases the mostly?
One is probably when PK must be part of most of the non-clustered index anyway.