Indexes slow down data changes.
SQL Server doesn’t have the concept of asynchronous indexes – copies of the data that it could update later when it’s bored. It has to keep every nonclustered index up to date, every single time you change data, like a delete/update/insert.
Mo’ indexes, mo’ problems.
That’s why in my Mastering Index Tuning class, I start my D.E.A.T.H. Method with Deduping and Eliminating indexes that aren’t getting used. You wanna get rid of the dead weight that’s only slowing you down, and it’s especially important before adding more indexes.
The safest indexes to remove are ones that:
- ARE being written to (because SQL Server has to keep them up to date) – I’m not as worried about archived or read-only tables
- Aren’t used for uniqueness constraints (because they might be influencing execution plans even though they’re not used)
- Aren’t columnstore indexes (because the presence of those can affect execution plans in other ways)
- Haven’t been used at all for reads in over a month straight (ensuring they’re not used in month-end processing, either)
But you’re busy, and you have a lot of databases and servers, and you don’t set yourself a reminder to check to see which servers have been up for 31+ days, and then go in and check the index utilizations. And even if you did, you wouldn’t want to script out all the undo scripts to back out your changes.
SQL ConstantCare® now includes drop & recreate commands in your daily prescription.
Every day when your diagnostic data comes in, we examine your index usage and server performance. When we find good candidates for removal, we script out both the drop & recreate commands in your prescription file for easy running:
As with all of our prescription recommendations, you just wanna read through ’em as a sanity check, then run ’em. Note that the indexes are even fully qualified with database names: that’s because we want to make it super-easy for you to fix all of your databases just by hitting execute.