Non-clustered index with all columns for "select * from"?

Question

I have a simple SELECT * FROM MyTable WHERE DataDate = '18-AUG-2013' query on a table that contains 340 columns and 3.4M rows.

Running estimated Execution plan in SSMS (Ctrl-L) suggests I create a non-clustered index on the DataDate and include every other column?

Is that a sensible thing to do (in general terms)? Seems to me that this would vastly increase the indexing space and the indexing time on inserts etc. ?

Answer 1

Definitely don't do that. The missing index hints can be very useful but the recommendations can be dumb, occasionally outright ridiculous. Creating a copy of the entire table for the benefit of this query fits the later.

If your most common queries use a predicate on DataDate then it may be appropriate to change your tables clustered index to this. Only you can make that call based on your understanding of the workload.

SELECT * on a 340 column table smells suspicious. Do you really need all of those columns, every time?

• ImmortalStrawberry: SELECT * is actually to archive data older than a certain date - which is to be followed by a delete from - hence NOT wanting to add that index!
• Martin Smith: @BlueChippy - What edition of SQL Server are you on? If Enterprise have you considered partitioning to quickly switch out archived data? In any event you can potentially combine the DELETE and the INSERT with the OUTPUT INTO clause to avoid the need for an INSERT ... SELECT followed by a DELETE.
• ImmortalStrawberry: On Standard, sadly (due to cost of Enterprise) - otherwise I'd be partitioning.
• vorou: Could you please clarify why it's always a bad idea? What would be the drawbacks (other than obvious writes slowing down)? What are the alternatives if, for example, I actually need all of these columns for queries A and B, both of which needs different ORDER BY columns?