You want faster queries, and you’re starting to read execution plans to figure out what to do.
You’ve been writing T-SQL queries for a few years now, and when you have performance issues, you’ve been updating stats and using OPTION (RECOMPILE). It’s served you well, but every now and then, you hit a problem you can’t solve. Your data’s been growing larger, your queries are taking longer to run, and you’re starting to wonder: how can I start getting better query plans?
The secret is often comparing the query plan’s estimated number of rows to actual number of rows. If they’re different, it’s up to you – not the SQL Server engine – to figure out why the guesses are wrong. To improve ’em, you can change your T-SQL, the way the data’s structured and stored, or how SQL Server thinks about the data.
This session won’t fix every query – but it’ll give you a starting point to understand what you’re looking at, and where to go next as you learn about the Cardinality Estimator.
Why I Want to Present This Session:
I want to ease performance tuners into the process of non-intuitive parts of execution plans.
Latest posts by Brent Ozar (see all)
- What to Do When SQL Server is Unusually Slow - February 25, 2018
- Getting Better Query Plans by Improving SQL’s Estimates - February 25, 2018
- How Often Should You Run Backups and CHECKDB? - February 25, 2018