Every query tuner wants to explain exactly how much faster we made a query.
But sometimes SQL Server Management Studio adds noticeable overhead to the query duration. For relatively fast queries that return more than a few rows, just the overhead of displaying the results can skew your duration metric.
Should you always index your foreign keys? What if you index them, and then the index never gets used?
I recently mapped out my thought process for how I approach a new instance of SQL Server when it comes to index tuning.
If you haven’t checked out Microsoft’s new WideWorldImporters sample database for 2016, it’s a pretty cool new little database. The database makes it easy to play around with new 2016 features, and it even ships with some cool little executables to run inserts in the “workload-drivers” folder.
Unique constraints and unique nonclustered indexes have a lot in common: unique constraints are implemented with a unique index behind the scenes.
While unique nonclustered indexes have a couple of additional features, I can still think of a scenario where it might be best to use unique constraints.
This is one of those little details that confused me a ton when I was first working with execution plans.
One problem with learning to work with plans is that there’s just SO MUCH to look at. And it’s a bit spread out. So, even when looking at a single tooltip, things can be confusing.
Let’s talk about the nested loop operator, who can be particularly weird to understand.
Learn what it’s like to find and develop your voice as a technical speaker in this week’s episode of Dear SQL DBA.
Copyright (c) 2025, Catalyze SQL, LLC; all rights reserved. Opinions expressed on this site are solely those of Kendra Little of Catalyze SQL, LLC. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.