Understanding SQL Server's Query Execution Plans
•Descargar como PPTX, PDF•
3 recomendaciones•3,229 vistas
Understanding query execution plans is something that a lot of IT professionals either don't know about or don't understand. SQL Server's programming language T-SQL is different from most other programming languages. In most languages you tell the language what you want it to do, in T-SQL you tell it what you want. This means you are at the mercy of the query optimiser which will take the logical instruction and convert it into a physical plan. The query execution plan is a map of what the optimiser thinks will be a good way of returning the data you have asked for. Being able to understand query plans and what they show is critical for both DBA's and developers in uncovering query performance problems. To view the webcast recording: http://dell.to/17k8zWK
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (12)
Más de SQLDBApros
Más de SQLDBApros (11)
Último
Último (20)
Understanding SQL Server's Query Execution Plans
- 1. Understanding Query Execution Plans Richard Douglas
- 2. Agenda • Introductions • The Query Optimizer • Commonly used operators • Blocking and non-blocking operators • Reading Query Execution Plans 2 Understanding Query Execution Plans Global Marketing
- 3. Your host • Richard Douglas • Systems Consultant • SQL Server MCITPro • Maidenhead SQL User Group Leader • Blog: http://SQL.RichardDouglas.co.uk • Twitter: @SQLRich • Email: Richard.Douglas@Software.Dell.com 3 Understanding Query Execution Plans Global Marketing
- 4. The Query Optimizer Why do we need an optimizer? • T-SQL is a “What” not “how” language. • We write “logical” requests. • SQL Optimizer Engine converts logical requests into physical plans. 4 Understanding Query Execution Plans Global Marketing
- 5. The Query Optimizer What is the goal of the Optimizer? The job of the SQL Optimizer is to find “the best plan possible”. 5 Understanding Query Execution Plans Global Marketing
- 6. Query optimization explained simply 1. Query submitted 2. Magic happens 3. Shedload of data returned 6 Understanding Query Execution Plans Global Marketing
- 7. Query Optimization (in a bit more detail) Optimizer steps Parse Bind Optimize Execute 7 Understanding Query Execution Plans Global Marketing
- 8. Parse Builds a tree structure based upon the logical operators in the query. For example: Logical Operations SELECT SSOD.[SalesOrderID], PP.[Name], PP.[Weight], SSOD.[UnitPrice] FROM [Sales].[SalesOrderDetail] SSOD INNER JOIN [Production].[Product] PP ON SSOD.ProductID = PP.ProductID WHERE PP.Weight > 100 Nodes Project Filter Join 8 Understanding Query Execution Plans Sales Order Detail Product Global Marketing
- 9. Bind • Series of validation steps • Schema validation • Table validation • Attribute validation • Permission validation SELECT SSOD.[SalesOrderID], PP.[Name], PP.[Weight], SSOD.[UnitPrice] FROM [Sales].[SalesOrderDetail] SSOD INNER JOIN [Production].[Product] PP ON SSOD.ProductID = PP.ProductID WHERE PP.Weight > 100 9 Understanding Query Execution Plans Global Marketing
- 10. Optimize Works though many rules and heuristics. These Include: • Commutativity • Substitution rules • Exploration rules • Implementation rules 10 Understanding Query Execution Plans Global Marketing
- 12. Statistics • SQL uses a cost based optimizer • Costs influenced by statistics 12 Understanding Query Execution Plans Global Marketing
- 13. Commonly used operators SELECT UPDATE INSERT DELETE Table scan Clustered Index Scan NonClustered Index Scan Clustered Index Seek NonClustered Index Seek Key Lookup Nested Loop Join Merge Join Hash Join 14 Understanding Query Execution Plans Global Marketing
- 14. Blocking and Non-blocking Operators • Operators / Iterators can be put in two categories: 1. Blocking 2. Non-blocking • Having a blocking operator in your plan means other operators further down the line are sitting idle. This will reduce the overall performance of your query • Some examples… 15 Understanding Query Execution Plans Global Marketing
- 15. Blocking and Non-blocking operators Non-blocking example • An example using a Compute Scalar function ? 16 Understanding Query Execution Plans Compute Scalar Function Row 1 Row 2 Row 3 Row 4 Row 5 Global Marketing
- 16. Blocking and Non-blocking operators Blocking example • An example using the sort operator: ? 17 Understanding Query Execution Plans Sort Desc Row 1 Row 2 Row 3 Row 4 Row 5 Global Marketing
- 17. Demo’s
- 18. Solution Area Product Description Backup and Recovery Fast, flexible backup and recovery with industry-leading compression technology Performance & Operations Discover and resolve performance issues in production before they impact end users and service levels Deepest possible understanding of database performance and norms Performance Tuning Plan and develop applications that deliver both functionality and Development optimal performance Comprehensive schema, object, security and change management Administration Community, Knowledge, Training Project Lucy © 2012 Quest Software Inc. All rights reserved. Community crowdsourcing for SQL Server tracing and performance information! Pg. 22
- 19. SQLRelay Dates @SQLRelay2013 11/11/13 – Reading 12/11/13 – Southampton 13/11/13 – Cardiff 14/11/13 – Birmingham 15/11/13 – Hemel Hempstead 25/11/13 – Newcastle 26/11/13 – Manchester 27/11/13 – Norwich 28/11/13 – Bristol 29/11/13 – London
- 20. Any questions? 24 Understanding Query Execution Plans Global Marketing
- 21. Thank you for attending Richard Douglas Richard.Douglas@Software.Dell.com @SQLRich
Notas del editor
- Heuristics quote from WikiPedia - The objective of a heuristic is to produce quickly enough a solution that is good enough for solving the problem at hand. This solution may not be the best of all the actual solutions to this problem, or it may simply approximate the exact solution. But it is still valuable because finding it does not require a prohibitively long time.Commutativity – In mathematics Commutativity is where sums can be rewritten and still provide the same answer, 10+100=110 & 100+10=110.The optimizer knows that if you are asking for an inner join (that is a join where the same data must be found on either side) then it would be more efficient to join the large table to the smaller one. This would result in less work for the storage engine. Let’s take the figures 10 & 100 again Table A will be 100 records, table b will be 10.Join A to b would require 100 searches into table b. join b to a would require 10 searches into table a – quite a saving and still the same logical outcome.In other words this part helps to work out the most efficient join order for your query. It’s been some time since we have had to worry about the order of our joins, the optimizer now figures that out for us.Substitution rules &Exploration rules - Substitution &Exploration rules are rules that use heuristics or mathematic rules to generate new tree shapes, this may provide the opportunity for more optimization rules.Implementation rules - Implementation rules convert the logical trees into physical trees, at this point they can be optimized further and become the eventual execution plan.
- Physical OperatorsPhysical operators implement the operation described by logical operators. Each physical operator is an object or routine that performs an operation. For example, some physical operators access columns or rows from a table, index or view. Other physical operators perform other operations such as calculations, aggregations, data integrity checks or joins. Physical operators have costs associated with them.The physical operators initialize, collect data, and close. Specifically, the physical operator can answer the following three method calls:Init(): The Init() method causes a physical operator to initialize itself and set up any required data structures. The physical operator may receive many Init() calls, though typically a physical operator receives only one.GetNext(): The GetNext() method causes a physical operator to get the first, or subsequent row of data. The physical operator may receive zero or many GetNext() calls.Close(): The Close() method causes a physical operator to perform some clean-up operations and shut itself down. A physical operator only receives one Close() call.The GetNext() method returns one row of data, and the number of times it is called appears as ActualRows in the Showplan output that is produced by using SET STATISTICS PROFILE ON or SET STATISTICS XML ON. For more information about these SET options, see SET STATISTICS PROFILE (Transact-SQL) and SET STATISTICS XML (Transact-SQL).The ActualRebinds and ActualRewinds counts that appear in Showplan output refer to the number of times that the Init() method is called. Unless an operator is on the inner side of a loop join, ActualRebinds equals one and ActualRewinds equals zero. If an operator is on the inner side of a loop join, the sum of the number of rebinds and rewinds should equal the number of rows processed on the outer side of the join. A rebind means that one or more of the correlated parameters of the join changed and the inner side must be reevaluated. A rewind means that none of the correlated parameters changed and the prior inner result set may be reused.ActualRebinds and ActualRewinds are present in XML Showplan output produced by using SET STATISTICS XML ON. They are only populated for the Nonclustered Index Spool, Remote Query, Row Count Spool, Sort, Table Spool, and Table-valued Functionoperators. ActualRebinds and ActualRewinds may also be populated for the Assert and Filter operators when the StartupExpression attribute is set to TRUE.When ActualRebinds and ActualRewinds are present in an XML Showplan, they are comparable to EstimateRebinds and EstimateRewinds. When they are absent, the estimated number of rows (EstimateRows) is comparable to the actual number of rows (ActualRows). Note that actual graphical Showplan output displays zeros for the actual rebinds and actual rewinds when they are absent.A related counter, ActualEndOfScans, is available only when Showplan output is produced by using SET STATISTICS XML ON. Whenever a physical operator reaches the end of its data stream, this counter is incremented by one. A physical operator can reach the end of its data stream zero, one, or multiple times. As with rebinds and rewinds, the number of end of scans can be more than one only if the operator is on the inner side of a loop join. The number of end of scans should be less than or equal to the sum of the number of rebinds and rewinds.