views:

356

answers:

1

In the DMV sys.dm_db_missing_index_group_stats, there is a field named avg_user_impact. Per BOL, this shows the

Average percentage benefit that user queries could experience if this missing index group was implemented. The value means that the query cost would on average drop by this percentage if this missing index group was implemented.

When I run a query to find the missing indexes that would have the greatest impact on performance, I see a few that claim the avg_user_impact will be in the thousands.

I built an index using one of these recommendations, and it was never used according to the DMV sys.dm_db_index_usage_stats. As soon as I disabled the index, it immediately showed up again as a missing index.

Is it possible that once the avg_user_impact field shows over 100, it's in error? Or is this an example of how a recommended index must still be tested for usefulness? What am I doing wrong or misunderstanding?

+1  A: 

The recommended indexes and user impact are both estimates from the cost optimizer, and, as you see there's no guarantee that they are always correct. I think the user impact column can be over 100 by design (though we'd have to hope a MS developer from the SQL Server team is responding here for the real answer.) It is always vital to test whether creating the indexes shown in the DMV will work or not. I have had the same experience where an index is shown there, but once created doesn't actually get used, perhaps due to the details of the query or the data distribution in the tables, etc. The view is right most of the time, especially for simple cases, but not always.

Also, be careful about creating really wide indexes, as they might hurt insert/update performance more than they help select performance, depending on how busy the server is.

onupdatecascade
One other thing - there's a really clever query to correlate query plans against recommended indexes here: http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/71814032-cd8d-4802-80de-7fb2bee80f41 also:http://sqlblog.com/blogs/jonathan_kehayias/archive/2009/07/27/digging-into-the-sql-plan-cache-finding-missing-indexes.aspx
onupdatecascade