Sanity check:
I have a non unique clustered key on an integer and I have a primary key on another integer identity column.
Should I add the primary key as a second column in the clustered key or not?
Using both columns in the clustered key gives 4 + 4 bytes. Using a non unique key gives 4 byte plus a 4 byte uniquifier and an extra 2 bytes because the uniquifier is variable length.
10 bytes for the non unique clustered key and 8 bytes for the two column unique clustered key plus that the primary key values will be part of every non clustered key seams like a no-brainer but I might have misse…
I have a non unique clustered key on an integer and I have a primary key on another integer identity column.
Should I add the primary key as a second column in the clustered key or not?
Using both columns in the clustered key gives 4 + 4 bytes. Using a non unique key gives 4 byte plus a 4 byte uniquifier and an extra 2 bytes because the uniquifier is variable length.
10 bytes for the non unique clustered key and 8 bytes for the two column unique clustered key plus that the primary key values will be part of every non clustered key seams like a no-brainer but I might have misse…
