- Listen on Spotify!
- Episode 5 Details Page – Watch it here
- Main Podcast Page – Check out all of our Season 3 episodes
When it comes to SQL Server performance, index and statistics maintenance is one of those areas where “good intentions” can quietly turn into serious problems. In a recent discussion, I sat down with Mitchell Glasscock to talk through what we call the seven deadly sins of index and statistics maintenance—and trust me, we’ve both seen these mistakes in the wild more times than we’d like.
One of the biggest offenders? Blindly rebuilding or reorganizing every index on a nightly basis. It sounds proactive, but in reality, it’s often just wasted I/O and CPU cycles. Not every index needs that level of attention, and doing it across the board can actually hurt performance, especially in larger environments.
Then there’s the long-standing “5% and 30% fragmentation rule.” This guideline has been floating around for years, but SQL Server workloads have evolved—and sticking to those numbers without context can lead to unnecessary maintenance. Fragmentation isn’t always the villain it’s made out to be.
In fact, one of the most overlooked areas is statistics. If I had to choose between perfect index fragmentation and up-to-date statistics, I’ll take good stats every time. The query optimizer depends heavily on accurate statistics, and stale stats can lead to poor execution plans far more often than fragmentation issues.
Another common mistake is spending time maintaining tiny indexes. If an index only has a handful of pages, rebuilding it isn’t going to move the needle. Your maintenance strategy should focus where it actually matters—on larger, more impactful structures.
We also talked about over-indexing. It’s easy to fall into the trap of adding indexes to fix every query, but too many indexes can slow down writes and increase maintenance overhead. Indexing should always be intentional and evidence-based.
Timing is another critical factor. Running aggressive maintenance jobs during peak hours can create blocking, slowdowns, and unhappy users. Maintenance windows exist for a reason—use them wisely.
And finally, don’t blindly trust third-party tools or built-in solutions like Maintenance Plans or Database Tuning Advisor. These tools can be helpful, but they don’t understand your workload the way you do. They should assist your strategy, not define it.
At the end of the day, the key takeaway is this: SQL Server maintenance should be driven by data, not habit. Measure what matters, focus on real bottlenecks, and adjust your approach based on evidence.
If any of this sounds familiar—or if you’re not sure whether your maintenance strategy is helping or hurting—this is exactly where we can help. At Stedman Solutions, we specialize in SQL Server performance tuning and proactive maintenance. Our managed services give you a team of experienced DBAs, continuous monitoring with Database Health Monitor, and real-world expertise to keep your systems running smoothly.
You can learn more about our Managed Services here: https://stedmansolutions.com/managed-services/
Or reach out directly to talk about your environment: https://stedmansolutions.com/contact-us/
Because when it comes to SQL Server, doing maintenance the right way makes all the difference.
Don’t miss out on our other episodes from Season 2
More from Stedman Solutions:
Steve and the team at Stedman Solutions are here for all your SQL Server needs.
Contact us today for your free 30 minute consultation..
We are ready to help!