Before you optimize: Understanding Execution Plans


Published on

You know what your query does, but do you know how it does it? Do you know what type of resources your query uses? This session covered these questions and more as we walked through reading execution plans. We saw how SQL breaks down the execution of your query and what each step tells us about the overall query. These slides provide the additional resources that go into the depth we couldn't get into in the session.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • What this presentation is NOT: Not about optimization. Use car illustration – check engine light is on. What does it mean? We will read the diagnostic information. We aren’t going to cover how to fix the problems we find. Identification is the step we are covering.
  • Roadmap the database uses to get the data most efficiently.Why is this important? We need to know if our assumptions are rightDiscuss cached plans / plan creation costPermissions needed to view plan: GRANT SHOWPLAN TO <user>SQL determines most efficient or “close enough” for simple plansOnly DML (not DDL) gets a plan cache (only one way to do DDL)
  • Demo #1
  • Demo #1
  • Demo #1
  • Demo #2
  • Invalidate cache by redoing indexes and other operations that would alter the plan’s effectiveness
  • Demo #1Query cost (relative to the batch)Right to LeftDemo #3Type of operation (scan, seek, etc.) – pragmatic approach to getting dataCost of operation (relative to query)Details ViewTable scan(heap) vs. Index scan
  • Demo #4
  • Ad hoc also get a value of zero in the cache (easily wiped out)
  • For example, if the parameter first used to call the query is on an indexed list and the value is found in five entries out of a thousand, the index will be used for the lookup. However, if the next time you pass in a value that can be found in 800 of the thousand records, a table scan would be a better option.
  • Size (of the arrow) matters
  • Before you optimize: Understanding Execution Plans

    1. 1. Before You Optimize:Understanding Execution Plans @IAmTimCorey
    2. 2. About Me• Worked with Microsoft SQL since 6.5• Started my career in VB6• Moved to .NET when it came out• Consultant, Adjunct Professor, Trainer, and Speaker
    3. 3. Agenda• Introduction to Execution Plans• Reading Execution Plans• Limitations• Additional Tools• Next Steps
    4. 4. What Are Execution Plans?
    5. 5. Basic Execution Plan
    6. 6. Types of Execution Plans Estimated ActualGraphical Ctrl + L Ctrl + MText SHOWPLAN_ALL STATISTICS PROFILE SHOWPLAN_TEXTXML SHOWPLAN_XML STATISTICS_XML
    7. 7. Estimated vs. Actual Details
    8. 8. List of Existing PlansSELECT [cp].[refcounts] ,[cp].[usecounts] ,[cp].[objtype] ,[st].[dbid] ,[st].[objectid] ,[st].[text] ,[qp].[query_plan]FROM sys.dm_exec_cached_plans cpCROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) stCROSS APPLY sys.dm_exec_query_plan(cp.plan_handle)qp;* From SQL Server Execution Plans by Grant Fritchey – p. 23
    9. 9. Execution Plan AgingFormula: Cost to compile * # of callsLazywriter: scans cache and decrements by oneeach scanClear Cache: DBCC FREEPROCCACHEItems are removed when:• Memory is needed• The age of the item is zero• The plan is not currently in use
    10. 10. How Do You Read an Execution Plan?
    11. 11. Rebind and RewindOccur on certain loop joins. They representeach time the system has to look through theinner table again for more data.Rebind – when the outer data changesRewind – when the outer data remains the sameMore info:
    12. 12. Limitations
    13. 13. Ad Hoc Query PlansAd hoc plans will use the cache as long as:• The schema is specified throughout• The text doesn’t change (at all*)* For queries with one table only, simpleparameterization will allow the parameters tochange while still reusing the cached plan. Toexpand this to more complex queries, see thisreference:
    14. 14. Parameter SniffingSQL Server designs execution plans based upon thefirst set of parameters passed in. This can haveadverse effects. To get around it, you can:• Use WITH RECOMPILE• Use tailored stored procs• Set a trace flag to disable parameter sniffing• Use the OPTIMIZE FOR query hint• Use sp_recompile to clear cache for stored proc or those that use a particular tableRead more here:
    15. 15. Additional Tools
    16. 16. SQL Sentry Plan Explorer
    17. 17. AutoEPLoader
    18. 18. SQL Server Profiler
    19. 19. How Do I Learn More?
    20. 20. Further Resources• Book by Grant Fritchey -• Index Statistics -• Query Parallelism -• Query Hints -
    21. 21. For questions, comments, and further information, catch me onTwitter at @IAmTimCorey or email