SQL Server optimizer features-dynamic retrieval

Original: SQL Server optimizer features-dynamic retrieval

Some time ago I wrote the article SQL Server implicit conversion caused by lying gun deadlock in some friends commented back said that in the SQL2008R2 test did not appear deadlock, their own measurement is true, so to everyone to bring the doubts expressed sorry, I'll explain the reason here.

Review: The cause of the deadlock in SQL2012 has been explained, because the table scan caused by the implicit conversion expands the lock size. But there is no such thing in sql2008r2, and it is clear that the lock size has not expanded because the optimizer of SQL Server did something extra for us-dynamic retrieval

Dynamic Retrieval: based on the benefits of index lookups, SQL Server (some versions) will attempt to convert some scenarios internally, making index retrieval more extensive and important additions.

Or an example of the previous one, the update execution plan we saw in SQL2008R2 1-1

Code Generation test Data

Create TableTestlock (IDvarchar(Ten)Primary Key Clustered, col1varchar( -), col2Char( $))Go----------Create test tableDeclare @i intSet @i = 1 while @i <  -beginInsert  intoTestlockSelect  Right(Replicate('0',Ten)+ cast(@i  as varchar(Ten)),Ten),'AAA','Fixchar'Set @i = @i+1EndGo----------Generate test Data

View Code

Code Deadlock Statement

Declare @ID nvarchar(Ten)begin Tran Select  Top 1 @ID =Id fromTestlock with(Updlock, Rowlock, Readpast)whereCol1= 'AAA'Order  byIdASCSelect  @IDwaitforDelay'00:00:20'UpdateTestlockSetCol1= 'BBB' whereId= @IDCommit Tran

View Code

Figure 1-1

You can see that because SQL Server has made the variable @id an additional conversion operation, so that it is processed as a numeric value, so that the index lookup to improve efficiency, this is the original intention of dynamic retrieval, but also at the same time to circumvent the occurrence of deadlocks.

About Dynamic retrieval

In the case of dynamic retrieval, the optimizer will set 0 of the estimated consumption of the constant, scalar computed cpu,io, to avoid the change of the size of the query subtree resulting in possible execution plan changes, and retrieve the corresponding retrieval range and retrieval mode as input of the query operation. 1-2

Figure 1-2

Implementation Details

You can see the output list in Figure 1-2 expr-1013,expr-1014,expr-1012 and in the actual execution, these three output objects represent the starting value of the constant, the ending value, and the action required to perform the operation, Open its XML execution plan details to see that the Expr-1013 value is @id, the Expr-1014 value is @id, the Expr-1012 value is 62, and 62 means "="

1-3 is shown

Figure 1-3

Another instance

Declare @ID nvarchar (ten) Set @ID = 0000000006 Update Set = ' BBB ' where > @ID

If it is greater then the corresponding XML execution plan 1-4

Figure 1-4

Note: its output expression means that the meaning of each version should be the same, but not verified.

Retrieve in output list the values of other operators mean that friends who are interested in the meaning can test the validation themselves.

PostScript: This behavior has been fed back to SQL Server related team.

Once again I wish you all the best of the goat!

SQL Server optimizer features-dynamic retrieval