Oracle中，为了减少系统内的硬解析，从而节省系统资源，有绑定变量、计划共享（通过cursor_sharing参数）等一系列措施。那么，SQL Server作为三大商业关系库之一，是否也存在这样的机制呢？答案是肯定的，下面，我们就一起来看看SQL Server系统中的类似机制。
SQL Server主要通过如下四个机制来缓冲之前执行过的查询的执行计划，以避免这些查询的再次编译，从而节省系统资源。
1）临时查询缓冲（Ad hoc query caching）；
2）自动参数化（parameterize automatically）；
3）准备查询（prepared queries）；
4）编译对象（compiled objects）；
下面，分别对SQL Server着四个机制介绍如下：
1）临时查询缓冲
SQL Server2005以前，临时计划偶尔也会被缓冲，但是我们不能指望这个特性发挥太多效果。即使后续版本中，当SQL Server缓冲临时计划时，被缓冲的这些计划也只有在随后的批处理文本和这些计划的文本完全匹配时，才能被重用。我们可以通过如下SQL语句来查询被缓冲的临时查询计划的被重用情况：
SELECT usecounts, cacheobjtype, objtype, [text]
FROM sys.dm_exec_cached_plans P
CROSS APPLY sys.dm_exec_sql_text (plan_handle)
WHERE cacheobjtype = 'Compiled Plan'
AND [text] NOT LIKE '%dm_exec_cached_plans%';
为了改善被缓冲的临时查询计划重用状况不佳的问题，SQL Server提供了一种特性，称之为临时负载优化选项（Optimize for Ad Hoc Workloads option），我们可以通过如下方式开启它：
EXEC sp_configure 'optimize for ad hoc workloads', 1;
RECONFIGURE;
GO
你也可以通过SQL Server management studio中服务器属性的高级页面开启这个特性。该特性被打开后，相同的临时查询第一次被编译时，会在计划缓冲中产生该语句的编译计划根（compiled plan stub），该计划根所占内存空间不会超过300个字节，包含指向该查询文本的指针。当该查询再次被编译时，被缓冲的计划根会被编译计划代替，而该编译计划比原来的计划根要大很多，要占用两个页大小的内存空间。
可以通过如下查询获取该特性开启后，被缓冲的编译计划根和编译计划的信息：
SELECT usecounts, cacheobjtype, objtype, size_in_bytes, [text]
FROM sys.dm_exec_cached_plans P
CROSS APPLY sys.dm_exec_sql_text (plan_handle)
WHERE cacheobjtype LIKE 'Compiled Plan%'
AND [text] NOT LIKE '%dm_exec_cached_plans%';
该特性开启后，还可以通过如下命令关闭：
EXEC sp_configure 'optimize for ad hoc workloads', 0;
RECONFIGURE;
GO
也可以通过SQL Server management studio中服务器属性的高级页面关闭该特性。
2）自动参数化
说到参数化，SQL Server又将其分为简单参数化（Simple parameterization）和强制参数化（Forced parameterization）两种情形。这有点类似Oracle中的cursor_sharing参数的使用。下面，我们就先说说简单参数化，简单参数化也是SQL Server的默认设置和行为。有时，SQL Server会地自动将查询中的常数参数化，随后的查询如果和参数化后的查询语句一样，将会重用之前参数化查询的缓冲的执行计划。同样，我们也可以通过如下语句对参数化的行为进行查询和分析：
SELECT usecounts, cacheobjtype, objtype, size_in_bytes, [text]
FROM sys.dm_exec_cached_plans P
CROSS APPLY sys.dm_exec_sql_text (plan_handle)
WHERE cacheobjtype = 'Compiled Plan'
AND [text] NOT LIKE '%dm_exec_cached_plans%';
GO
结果中，针对每个带常数的查询，会产生一个被缓冲的编译计划，这些临时查询作为壳查询（shell query）的编译计划被缓冲，目的就是为了后续相同常数查询发现查询的参数化版本更容易些，这些常数查询被缓冲的编译计划占用内存空间较小，大概为两个页大小，也并不包含完全的编译计划。而针对所有这些常数查询，系统也会生成一个参数化的查询，该查询称为准备查询（prepared query），这个准备查询的编译计划才是完整的编译计划，因此，占用内存空间也会更大些，大概为四个页大小。
说完了简单参数化，下面，我们说说强制参数化。
有时，你的应用用了很多类似的语句，而且，你认为可能会从编译计划重用中获益，但遗憾的是，系统并不能将这些类似的语句参数化。此时，SQL Server提供了一个数据库选项，那就是PARAMETERIZATION FORCED，可通过如下命令对该选项进行设置：
ALTER DATABASE <database_name> SET PARAMETERIZATION FORCED;
设置该选项后，SQL Server就会将相关查询中常数参数化，但也会有些例外，具体可查询微软官方或其他文档。值得注意的是，这种为了重用缓冲编译计划，将查询中常数一概参数化的做法，有时也可能会带来严重的性能问题，因此，实际应用时，一定要具体问题具体分析。
3）准备查询
如上所述，SQL Server参数化的查询可以在计划缓冲区中生成准备查询类型的编译计划。此外，另外两种方法也可以生成准备查询类型的编译计划。但是，他们和SQL Server参数化的查询不同，这两种方法中用户可以自己决定参数的数据类型。其一是通过T-SQL批处理调用sp_executesql内置过程；其二是通过客户端应用使用准备和执行方法。这两种方法，有点类似Oracle中的绑定变量使用。
sp_executesql过程：使用该过程要求用户确定参数和它们的数据类型，具体语法如下所示：
sp_executesql @batch_text, @batch_parameter_definitions,param1,...paramN
只要通过相同@batch_test和@batch_parameter_definitions参数值调用该过程，就会重用缓冲中的统一编译计划。例如：
EXEC sp_executesql N'SELECT c2, c3, c4 FROM test.t1 WHERE c1 = @p', N'@p int', 1;
EXEC sp_executesql N'SELECT c2, c3, c4 FROM test.t1 WHERE c1 = @p', N'@p int', 2;
EXEC sp_executesql N'SELECT c2, c3, c4 FROM test.t1 WHERE c1 = @p', N'@p int', 3;
准备和执行方法：该方法和sp_executesql过程类似，但不尽相同。该方法并不需要运行时每次都要传送全部批命令文本，而是，只要在准备阶段传送一次即可，然后，返回的句柄可供每次运行批命令时使用。然而，该方法会在计划缓存区生成准备查询的编译计划，但并不会生成类似自动参数化中相应的临时壳查询计划。同样，我们可以通过如下查询获取编译计划相关信息：
SELECT usecounts, cacheobjtype, objtype, size_in_bytes, [text]
FROM sys.dm_exec_cached_plans P
CROSS APPLY sys.dm_exec_sql_text (plan_handle)
WHERE cacheobjtype = 'Compiled Plan'
AND [text] NOT LIKE '%dm_exec_cached_plans%';
GO
4）编译对象
计划缓存区中，除了包含之前讲到的临时查询编译计划和准备查询的编译计划，还包含第三种编译计划，那就是过程类型（PROC），该类型计划主要由存储过程、用户定义的标量函数和多语句表值函数等，用户可以完全控制这些对象参数的值和类型。这些对象的成功执行，都会重用计划缓存的之前运行的相同对象的编译计划。然而，用户也可以通过选项或重建，来强制这类对象生成新的编译计划，例如：
--存储过程
EXEC P_Test 'EM';
GO
EXEC P_Test 'IN';
GO
EXEC P_Test 'IN' WITH RECOMPILE;
--函数
DECLARE @p1 char(11);
EXEC @p1= test. f_test '123456789';
SELECT @p1;
GO
DECLARE @p1 char(11);
EXEC @p1 = test. f_test '987654321';
SELECT @p1;
GO
DECLARE @p1(11);
EXEC @p1 = test.f_test '987612345' WITH RECOMPILE;
同样，我们可以通过如下查询语句获取编译计划相关信息：
SELECT usecounts, cacheobjtype, objtype, size_in_bytes, [text]
FROM sys.dm_exec_cached_plans P
CROSS APPLY sys.dm_exec_sql_text (plan_handle)
WHERE cacheobjtype = 'Compiled Plan'
AND [text] NOT LIKE '%dm_exec_cached_plans%';
GO