RDS SQL Server - Topic Sharing - Key Lookup Using Execution Plan Cache Skillfully

Original link: http://click.aliyun.com/m/26465/
Abstract: # Background The introduction of execution plan caching is a very important feature in SQL Server memory management. This article is the fourth of a series of articles on the clever use of execution plan caching. Discusses what a Key Lookup operation is, how to spot a Key Lookup problem from the execution plan cache, and how to fix it. # What is Key Lookup The Key Lookup operation refers to the bookmark lookup method in which the execution plan looks up the field column through the index of the table. Key Lookup occurs when a query statement is

introduced using the Index Se background
. Execution plan caching is a very important feature in SQL Server memory management. This article is the fourth in a series of articles on the clever use of execution plan caching. Found Key Lookup issue in plan cache and how to fix it.

What is Key Lookup
Key Lookup operation refers to the bookmark lookup method in which the execution plan looks up the field column through the index of the table. Key Lookup occurs when the query statement uses Index Seek (or Index Scan) and needs to find additional column columns that are not fully included in the Index. At this time, SQL Server must go back and obtain the value of the additional column columns. Usually, the Key Lookup operation uses the table clustered index to find the value of the field column. Therefore, it may lead to expensive query performance overhead. In the performance optimization process, we need to pay enough attention.

How to find out Key Lookup
In the performance optimization process, the Key Lookup operation in the execution plan is one of the key points of our optimization, so how do we discover the Key Lookup operation? This article introduces two methods:
Graphic display
of execution plan Search in the

execution Graphical display of execution plan
The SQL Server client tool SSMS can visually display the execution plan graph in a graphical way. We can discover the Key Lookup operation through this intuitive graph. For example, we have the following query statement. Before executing, we turn on the actual execution plan collection switch (you can use the shortcut key CTRL + M).

USE [AdventureWorks2008R2];
GO

SELECT
    NationalIDNumber,
    HireDate,
    MaritalStatus
FROM HumanResources.Employee WITH(NOLOCK)
WHERE NationalIDNumber = N'519899904'; After the
GO
statement is executed, there will be an Execution Plan window, from which we can easily see the Key Lookup event operation, hover the mouse over the Key Lookup event, there will be a pop-up window to display more detailed information. For details, see the screenshot below. We can see that the performance overhead of Key Lookup is 50%, accounting for half of the performance overhead of the entire query statement. The cost is high.
01.png

Find in the execution plan
cache In addition to discovering the Key Lookup operation through the graphical display of the execution plan, we can also search the execution plan cache to make the Key Lookup operation invisible. For example, the information in the screenshot below is the XML node of the Key Lookup operation in the execution plan cache of the statement just executed.
02.png

Therefore, we only need to search the execution plan cache to find out which executed statements use the Key Lookup operation, and then perform targeted performance optimization. Find the execution plan cache as follows:

;WITH XMLNAMESPACES (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT 
        --TCquery('.')
        database_name = TCvalue('(IndexScan/ Object/@Database)[1]','sysname')
        ,Schema_name = TCvalue('(IndexScan/Object/@Schema)[1]','sysname')
        ,Table_name = TCvalue('(IndexScan/Object/@Table )[1]','sysname')
        ,Index_name = TCvalue('(IndexScan/Object/@Index)[1]','sysname')
        ,index_type = TCvalue('(IndexScan/Object/@IndexKind)[1] ','sysname')
        ,sql_text = TCvalue('(../../../../@StatementText)[1]',
        ,output_columns =STUFF(( SELECT DISTINCT ', ' + cr.n.value('(@Column)[1]', 'sysname')
                            FROM T.C.nodes('../../OutputList/ColumnReference') as cr(n)
                            FOR XML PATH('')
                            ), 1, 2, '' )
        ,seek_columns =STUFF(( SELECT DISTINCT ', ' + cr.n.value('(@Column)[1]', 'sysname')
                            FROM T.C.nodes('IndexScan/SeekPredicates/SeekPredicateNew/SeekKeys/Prefix/RangeColumns/ColumnReference') as cr(n)
                            FOR XML PATH('')
                            ), 1, 2, '' )
        ,Predicate = TCvalue('(IndexScan/SeekPredicates/SeekPredicateNew/SeekKeys/Prefix/RangeExpressions/ScalarOperator/@ScalarString)[1]', 'nvarchar(max)')
        --,cp.usecounts
        --,qp.query_plan
FROM sys .dm_exec_cached_plans AS cp
    CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) as qp
    CROSS APPLY qp.query_plan.nodes('/ShowPlanXML/BatchSequence/Batch/Statements/StmtSimple/QueryPlan/RelOp/NestedLoops/RelOp[IndexScan[@Lookup=" 1"] and IndexScan/Object[@Schema!="[sys]"]]') as T(C)
WHERE TCexist('../RelOp[IndexScan[@Lookup="1"] and IndexScan/Object[@ Schema!="[sys]"]]') = 1
For example, the execution statement just now was caught, and the screenshot is shown below:
03.png

Solve the Key Lookup problem
From the above analysis, we know the impact of Key Lookup on performance and how to find the statement of Key Lookup operation. The next task is how to solve the Key Lookup problem. Usually we have the following methods:
 Delete unnecessary column columns
 Create a covering index

Delete unnecessary column columns
This solution is easy to understand, because the purpose of using the Key Lookup operation is to find the column columns in the SELECT clause. If it is unnecessary, or if you want to delete the unnecessary column, it is very likely that SQL Server will not go through the Key Lookup operation, so this problem is solved. A very typical scenario is that many developers like to use the SELECT * FROM operation. The best way is to display the field names that must be used by all businesses, rather than querying all the fields in one go.

Create a Covering Index
If all the fields in the SELECT are necessary for your business and cannot be deleted, we can use a covering index to solve the Key Lookup problem, that is, when creating an index, use the INCLUDE clause to convert the fields after the SELECT Included in it (exclude fields in the ON clause, such as the NationalIDNumber field column here). For example, for the above query, we can create a covering index:

USE [AdventureWorks2008R2];
GO

CREATE NONCLUSTERED INDEX IX_NationalIDNumber_@HireDate_@MaritalStatus
ON HumanResources.Employee (NationalIDNumber)
INCLUDE(HireDate, MaritalStatus)
After WITH(FILLFACTOR = 90, ONLINE = ON) is
executed, execute the statement again and check the execution plan. There is only one Index Seek and no Key Lookup operation, indicating that this problem has been solved. See the screenshot below for details:
04.png

Friendly reminder
If you use SSMS to view the actual execution plan of executing the SQL statement, the Lookup attribute value of the IndexScan node in XML is True, as shown below:

...
<IndexScan Lookup="true" Ordered="true " ScanDirection="FORWARD" ForcedIndex="false" ForceSeek="false" ForceScan="false" NoExpandHint="false">
...
and the Lookup attribute value of the IndexScan node obtained from the execution plan cache is 1. It looks like this:

...
<IndexScan Lookup="1" Ordered="1" ScanDirection="FORWARD" ForcedIndex="0" ForceSeek="0" ForceScan="0" NoExpandHint="0">
...
Therefore, when we analyze the Key Lookup operation in the execution plan cache, we need to check whether the value of Lookup is 1, instead of checking whether it is true. The following is the XML node in the SSMS execution plan, the Lookup attribute value is true, and in the screenshot in the "Lookup in the Execution Plan Cache" chapter, we know that the Lookup attribute value is 1.
05.png

Final summary
This article discusses a point that needs to be optimized in the performance optimization process called Key Lookup operation, and how we found Key Lookup, and finally talked about two methods to solve the Key Lookup problem.

Quoted article
Finding Key Lookups inside the Plan Cache

If you find any content suspected of plagiarism in this community, please send an email to: [email protected] to report and provide relevant evidence. Once verified, this community will immediately delete the suspected plagiarism Infringing Content.
Original link: http://click.aliyun.com/m/26465/