Good list here. A few things I would add about execution plans specifically. 1. SET STATISTICS IO ON. This is much more useful than setting time on imo. This w

Good list here. A few things I would add about execution plans specifically. 1. SET STATISTICS IO ON. This is much more useful than setting time on imo. This will give you physical / logical reads per table as well as how specifically they were fetched. Usually I don't care if the query took 11 seconds, I want to know what took those 11 seconds. 2. The % numbers that everyone relies on when skimming execution plans are total BS. No one seems to realize this, but the percentage values are based off of the estimated query plan even when you're running the actual execution plan. Use the plan to determine which operators were chosen, disregard the % values. To get the true amount of work done, look at stats IO above. If your underlying issues is missing or stale stats for example, that incorrect data will pass through to your execution plan and that plan will lie to you. 3. Try to determine why a plan is getting generated. Don't just keep trying wacky code changes until you can get the correct plan (once..), find out what the optimizer is seeing and why it's doing what it's doing. You may know what operation is best in the current moment ("this was much faster as a nested loop") but instead of using a join hint, force the optimizer's hand by correcting whatever underlying issue is making it think that the merge/hash is a better route. This will save future-you hours of head-bashing when, inevitably, that join hint that was added three years ago causes a big production issue.