Is it bad to have a non-clustered index that contains the primary key from the clustered index?

Question

If you have a table with a clustered index on the Primary Key (int), is it redundant and bad to have one (ore more) non-clustered indexes that include that primary key colum

Answer 1

I'm with Remus on this - a clustered index is not really an index - it tells you how the data is organized in pages. (In your case, it's also the primary key, but that's not required to be the same thing). Non-clustered indexes include that row locator information, so yes, it is redundant.

But if a non-clustered index is covering and the data row bookmark doesn't need to be used, it can be used a lot more efficiently than the clustered index, and the efficiency increases as the ratio of the size of the data row to the size of the non-clustered index increases.

I've found that if you have a good handle on the access paths in your query workload, that sometimes a few selective covering non-clustered indexes often can be used to eliminate clustering choices completely - heap table, a PK, and some good non-clustered indexes, and you're done.