Analyzing Execution Plans Like a Pro Guy Glantser Image courtesy of Chris Sharp / FreeDigitalPhotos.net

A Few Words about Me… Name: Guy Glantser Email Address: guy@madeiradata.com Twitter: @guy_glantser Blog: www.madeiradata.com/author/guy Podcast: www.sqlserverradio.co.il Image courtesy of Mister GC / FreeDigitalPhotos.net

A Few Words about Me… Name: Guy Glantser Email Address: guy@madeiradata.com Twitter: @guy_glantser Blog: www.madeiradata.com/author/guy Podcast: www.sqlserverradio.co.il Image courtesy of Mister GC / FreeDigitalPhotos.net

Agenda Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Summary Compare Session Settings Each combination of the session settings produces a different execution plan. By default, the SQL Native Client sets ARITHABORT to False, while SQL Server Management Studio sets this option to True. Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Summary Cost is Always Estimated! Even when you look at the actual execution plan, the cost is estimated. There is no such thing as actual cost. If there is a difference between the estimated and the actual number of rows, then don’t trust the cost. Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Summary Compare Estimated vs. Actual Number of Rows Most performance problems will have this as a symptom. Find the operator in which there is a big difference between the estimated and the actual number of rows, and in most cases this will lead you to the root of the problem. Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Summary Nested Loops can be Misleading In the inner operator of a Nested-Loops join, the estimated number of rows reflects the number of rows per iteration, while the actual number of rows reflects the total number of rows. Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Summary Never Use Table Variables! Table variables don’t have associated statistics, so the optimizer always assumes there is a single row in them. This leads in many cases to serious performance problems, especially when the table variable is involved in a join operation. Prefer temporary tables whenever you can. Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Summary Read Execution Plans in Both Directions Reading an execution plan from right to left is helpful in understanding the data flow, while reading an execution plan from left to right is helpful in understanding the runtime execution flow. Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Summary Tooltips are Just Tooltips You can also use: Operator properties ShowPlan XML Trace flags Debugger (only if your name is Paul White) Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Summary Avoid Using Scalar Functions Although they make sense in terms of modularity and reusability, they really suck in terms of performance. In many cases, it is possible to rewrite the scalar function as an inline function, thus enjoying modularity, reusability and good performance together. Image courtesy of Chris Sharp / FreeDigitalPhotos.net

Questions? Image courtesy of Master isolated images / FreeDigitalPhotos.net

Image courtesy of David Castillo Dominici / FreeDigitalPhotos.net

Stay In Touch… Name: Guy Glantser Email Address: guy@madeiradata.com Twitter: @guy_glantser Blog: www.madeiradata.com/author/guy Podcast: www.sqlserverradio.co.il Image courtesy of Nuttapong / FreeDigitalPhotos.net