SQL Server parameterized scripts and automatic parameterization (simple parameterization)

If you execute an SQL statement without parameters, SQL Server internally parameterize the statement to increase the likelihood of matching it to an existing execution plan. This process, known as simple parameterization (in SQL Server 2000, called Automatic parameterization), ultimately results in the execution of plan reuse.

-- Remove all caches from the data buffer pool DBCC dropcleanbuffers     GO -- remove all cached execution plans from the execution plan buffer DBCC Freeproccache         GO

--executes an SQL statement with no arguments, and SQL Server internally parameterize the statement to increase the likelihood of matching it to an existing execution plan.

-This process is called simple parameterization (in SQL Server 2000, called Auto-parameterization) and ultimately performs the effect of plan reuse.  Select *  fromWorkItem TwhereT.workitemid= '67f956f5-a350-4254-b214-84b72c85664e'GoSelect *  fromWorkItem TwhereT.workitemid= 'b1e337b3-9b2a-4463-9692-7a738ebba205'GoSelect *  fromWorkItem TwhereT.workitemid= 'C059be96-aea3-42a1-8f66-b67c0dd79fa6'Go--using parameterized methods to executesp_executesql N'SELECT * from WorkItem t where T.workitemid = @wid', N'@wid varchar (+)',@wid='67f956f5-a350-4254-b214-84b72c85664e' 

Go

sp_executesql N'SELECT * from WorkItem t where T.workitemid = @wid', N'@wid varchar (+)',@wid='b1e337b3-9b2a-4463-9692-7a738ebba205'Gosp_executesql N'SELECT * from WorkItem t where T.workitemid = @wid', N'@wid varchar (+)',@wid='C059be96-aea3-42a1-8f66-b67c0dd79fa6'GoSELECTCacheobjtype, ObjType, Usecounts, refcounts, pagesused, SQL fromsys.syscacheobjectsWHERECacheobjtype= 'Compiled Plan'  andSql not  like '%syscacheobjects%'  andSQL like '%from WorkItem t where%'

--If the SQL script content is long, you can use Sys.dm_exec_cached_plans, sys.dm_exec_sql_text

SelectT.cacheobjtype, T.objtype, t.usecounts, T.refcounts, DC.text  fromSys.dm_exec_cached_plans T Crossapply Sys.dm_exec_sql_text (t.plan_handle) DCwhereT.cacheobjtype= 'Compiled Plan'  anddc.text  not  like '%dm_exec_cached_plans%'  andDC.text  like '%from WorkItem t where%'

Of course, as you can see from the final execution plan cache, directly executed SQL scripts will still have a corresponding record in the cache. The first SQL executed will generate two execution plans, one of which is to parameterize the obvious constants and then build your own Adhoc execution plan based on this parameterized execution plan. Subsequent SQL hits have generated an execution plan that can save a fraction of the compilation time.

As you can imagine, the execution plan for non-parameterized SQL still needs to be stored in database memory, and for the new SQL script, SQL Server also needs to follow a certain algorithm to find the corresponding parameterized execution plan, do not know how much of these need to spend resources? It is not yet clear how to view this type of information.

The following results are tracked by SQL Server Profiler:

SQL Server parameterized scripts and automatic parameterization (simple parameterization)