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. ?

1 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?

  • 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!
    – BlueChippy
    Aug 19, 2013 at 10:51
  • @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. Aug 19, 2013 at 11:14
  • On Standard, sadly (due to cost of Enterprise) - otherwise I'd be partitioning.
    – BlueChippy
    Aug 19, 2013 at 11:21
  • 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?
    – vorou
    Sep 17, 2018 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.