The query processor does what the query plan tells it to do A “good” query plan is essential for a well- performing query We must learn to identify and fix the mistakes The optimizer makes mistakes

LOGIC Flows Left-to-Right DATA Flows Right-to-Left

Iterators expose row and execution estimates Slow plan? Analyze estimates against actual values Important: Cost is always an estimate! Actuals and estimates way off? Try updating statistics

Thicker lines means more rows Make thick lines thinner, further to the right, for faster plans!

Slow Plan? Start here… Bonus Iterator! Scan

Your nonclustered index handles your search argument… … but you’re referencing at least one column that’s not included Lots of rows? You’ve got a problem

Used as a “cache” in the query processor Lack of adequate indexes or uniqueness information Implemented as hidden tables in tempdb Almost never a good sign

ORDER BY, Merge Join, Stream Agg, Windowing Performs worse, relative to input size, as input size increases Check expectations and indexes! Do you really need that sort?

Aggregation and join methodology Linear scale, but may heavily impact tempdb Common in warehouses Generally not good for OLTP

Basic join methodology Works best with a small outer (top) input Never-ending “hung” queries? Almost always inappropriate nested loops!

Much reviled by DBAs Often appropriate Check your predicates and expectations!

Most plan problems boil down to a simple set of issues Don’t let yourself get overwhelmed Most of all, have fun! Query tuning is a satisfying endeavor Focus on the obvious: lots of rows and problematic iterators