The Ultimate Index Usage Reporter

  • Comments posted to this topic are about the item The Ultimate Index Usage Reporter

  • This is nice! Could you please provide a description of what the following columns mean:

    user_seeks

    system_seeks

    user_scans

    system_scans

    user_lookups

    system_looksups

    user_updates

    system_updates

    score

    What should I bee looking for here? What red flags should I look for?

    Also, the index_columns_include never has any columns in it.

    Best Regards,

    ~David

  • user_* is anything initiated by the user

    system_* is anything initiated by the server - statistics updates etc...

    Seeks are seek operations (index seek, clustered index seek)

    Scans are scan operations (index scan clustered index scan)

    Lookups are only applicable to clustered indexes. They are bookmark lookups caused by when the nonclustered index not containing (seek or include) all the columns in the query (SELECT columns, JOIN predicates, WHERE predicates, ORDER BY columns). The SSMS built-in report do not report lookups.

    The score in general is (seeks*10+scans+1)/(updates+1). Clustered indexes don't get penalized for updates since every table should have one, but if a nonclustered index has a higher score, you should consider changing your clustered index. Higher scores mean useful indexes, low scores mean indexes that cause more overhead than benefit. Scanning cost isn't taken into account - it is just usage vs maintenance. But a score below 0.0001 is almost for certain a useless index.

    If your index_columns_include is always blank, then none 0f your indexes have include coluimns. Include columns are available for covering the query, but not for seeks - they are leaf level only. CREATE INDEX IX_table_seekcolumns_includecolumns ON dbo.table (Seek Columns) INCLUDE (Include Columns)

  • Thank you for the explanation. That helps a lot. 🙂

    -David

    Best Regards,

    ~David

  • This is a nice script. I have a similar one I have been using and I made some improvements based on what you did. Thanks for sharing.

    One thing to note: your ORDER BY clause very complex. When I ran this on a small VM it choked and literally told me the query was too hard (not enough memory, I think). I chopped off the ORDER BY and it worked fine. For me this doesn't matter because I copy the results into a spreadsheet and do my analysis there.

    I don't really understand your "score" column. Is it to show the indexes that are most important?

    I recently ran across the following article with scripts from Jason Strate that also deal with analyzing indexes, but he has taken it to a whole other level.

    http://www.sqlservercentral.com/blogs/stratesql/2012/12/18/index-analysis-the-re-return/

  • Thanks for the script.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply