The top queries can be determined with traces or from DMO sys.dm_exec_query_stats.

Check the improvement of each individual query.

Make sure the Fill Factor is appropriate for the index.

Make sure all indexes are actually useful. I’ve seen people add 1 index for each column, even if the selectivity is low, and they rarely query that column. Too many indexes on a table with a lot of modifications is not good. In an OLTP database, you need to be more selective on the indexes you add.

Unused indexes are a performance lag when it comes to modifying data; each index that is affected by updates/deletes/inserts will have to be rebuilt.

Luckily we have a DMV that can help us – sys.dm_db_index_usage_stats

From this DMV we can get an understanding of the “hits” an index gets, i.e. how many times it has been used, by summing (user_seeks + user-scans + user_lookups), vs the “updates” (user_updates)

An index that has many “updates” but few “hits”, may be one for review. I say “may”, as you would still have to ensure that it wasn’t that one critical index that is used for year-end reporting, and you would have to decide whether it was better to create the index for the time it was required, and then drop it ; or keep the index as-is.

Too often I see junior level folks willing to create an index without much regard to actual need. Workloads change, servers change, needs change–it’s good to look at this from a routine maintenance perspective like mowing the grass.

Using the following DMVs figure out what’s going on. Here are a few of my faves:

1) sys.dm_db_index_usage_stats
2) sys.dm_db_missing_index_details
3) sys.dm_db_missing_index_groups
4) sys.dm_db_missing_index_group_stats

These joined back to sys.indexes and other tables can give pretty good insight into what actions to take.

Once the evidence has been gathered on what needs to be done, then gradually add the changes and revisit the above DMVs to be sure you’ve gotten it right.

Rinse and Repeat.

2. Pay attention to the sequence of the columns. Vital statistics are kept on the distribution of values within the first column of the index, and somewhat lesser information is kept on values in the second column. If you find your queries doing a lot of index scans instead of index seeks, even a covering index will run slowly.

2. Where all columns can’t be included due to disk space constraints or other maintenance reasons, try to at least keep an index that covers all the columns for in the queries’ JOINs or WHERE clauses.

3. Consider partitioning indexes over large tables. I have a general rule of thumb that if the table is large enough to partition, so is an index over that table.

4. Use the new filtered index functionality where appropriate. If you can filter out most of the rows in the table at the index level prior to a query it can be a boost. But be sure to test your queries to make sure they actually use the filtered index.

5. Don’t forget about indexed views. If you can afford the disk space and maintenance overhead, they can take the JOIN load away.

6. Last but not least, pay careful attention to the sort order of the indexes. If there is a usual ORDER BY order in which queries are run (for example: region/customer/sales date descending), then having an index already in that sequence can give you the sort for “free” at query runtime, which can be a major boost to speed.

Separate your non-clustered indexes from your table and place them on a different filegroup (which should be logically be placed on a different disk, but I have seen the worst)…