在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的其他因素的情况下,比如重建索引,更新统计信息等等),
  一是基于WITH RECOMPILE的存储过程级别重编译,另外一种是基于OPTION(RECOMPILE)的语句级重编译。
  之前了解的比较浅,仅仅认为是前者就是编译整个存储过程中的所有的语句,后者是重编译存储过程中的某一个语句,也没有追究到底是不是仅仅只有这么一点区别。
  事实上在某些特定情况下,两者的区别并非仅仅是存储过程级重编译和语句级重编译的区别,
  从编译生成的执行计划来看,这两种强制编译的方式内在机制差异还是比较大的。
  这里同时引申出来另外一个问题:The Parameter Embedding Optimization(怎么翻译?也没有中文资料中提到The Parameter Embedding Optimization,勉强翻译为“参数植入优化”)

  本文通过一个简单的示例来说明这两者的区别(测试环境为SQL Server2014)。这里首先感谢UEST同学提供的参考资料和指导建议。

WITH RECOMPILE 和 OPTION(RECOMPILE)使用上的区别

  关于存储过程级别的重编译,典型用法如下,在存储过程参数之后指定“WITH RECOMPILE” 

CREATE PROCEDURE TestRecompile_WithRecompile
(
@p_parameter int
)WITH RECOMPILE
AS
BEGIN
SET NOCOUNT ON;
SELECT * FROM TestRecompile WHERE Id = @p_parameter OR @p_parameter IS NULL
END
GO

  关于语句级重编译,典型用法如下,在某一条SQL语句的末尾指定OPTION(RECOMPILE)

CREATE PROCEDURE TestRecompile_OptionRecompile
(
@p_parameter VARCHAR(50)
)
AS
BEGIN
SET NOCOUNT ON;
SELECT * FROM TestRecompile WHERE Id = @p_parameter OR @p_parameter IS NULL OPTION(RECOMPILE)
END
GO

  按照惯例,先搭建一个测试环境
  创建一张TestRecompile的表,也即上面存储过程中用到的表,插入100W行数据,Id字段上建立一个名字为idx_id的索引

CREATE TABLE TestRecompile
(
Id int,
Value varchar(50)
)
GO DECLARE @i int = 0
WHILE @i<=1000000
BEGIN
INSERT INTO TestRecompile VALUES (@i,NEWID())
SET @i = @i+1
END CREATE INDEX idx_Id ON TestRecompile(Id)
GO

WITH RECOMPILE 和 OPTION(RECOMPILE)使用时重编译生成的执行计划的异同

  如果说With Recompile存储过程级的重编译和Option Recompile的SQL语句级的重编译效果是一样的话,
  由上面的存储过程可知,存储过程中仅仅只有一句SQL代码,那么存储过程级别的重编译和SQL语句级别的重编译都是编译这一句SQL
  如果这样的话,两者在输入同样参数的情况下执行计划也应该是一样的,那么到底一样不一样呢?

  首先来看TestRecompile_WithRecompile这个存储过程的执行计划,可以看到是一个索引扫描(INDEX SCAN)

  

  然后再来看TestRecompile_OptionRecompile的执行计划,带入同样的参数

  

  至此,可以看出,虽然都用到索引,很明显第一个语句是索引扫描(INDEX SCAN),第二个语句是索引查找(INDEX SEEK)
  可以证明:在存储过程级指定 WITH RECOMPILE 强制重编译 和SQL语句级指定的OPTION(RECOMPILE)强制重编译,相同条件下生成的执行计划是不一样的。

为什么WITH RECOMPILE强制重编译 和 OPTION(RECOMPILE)强制重编译得到的执行计划是不一样的?

  WITH RECOMPILE强制重编译是每次运行存储过程,都根据当前的参数情况做一次重编译,
  首先我们暂时先不纠结为什么第一种方法用不到索引查找(INDEX的SEEK)。
  事实上正式因为使用了Id = @p_parameter OR @p_parameter IS NULL这种写法导致的,具体我后面做解释。
  那么对于OPTION(RECOMPILE)强制重编译存储过程中同样写法的SQL语句,为什么有能用到索引了呢?
    因为在用OPTION(RECOMPILE)强制重编译的时候,这里涉及到一个“Parameter Embedding Optimization”编译问题,
  事实上我之前也没有听说过这个名词,直译过来就是“参数植入编译”(不知道恰不恰当)
    OPTION(RECOMPILE)强制重编译在一定程度上增强和优化重编译的效果,
  参考这里:https://sqlperformance.com/2013/08/t-sql-queries/parameter-sniffing-embedding-and-the-recompile-options,文章中分析的极度牛逼,案例也非常精彩

  原文中是这么解释的:
  The Parameter Embedding Optimization takes this process a step further: query parameters are replaced with literal constant values during query parsing.
  The parser is capable of surprisingly complex simplifications, and subsequent query optimization may refine things even further. 
     翻译过来大概意思就是:
  相比WITH RECOMPILE这种强制重编译的方式,OPTION(RECOMPILE)中的Parameter Embedding Optimization机制更进一步,解析查询的过程中,参数值被字面常量所替代
  解析器神奇地把复杂的问题简化。至于怎么简化了,还是强烈建议参考原文,演示的案例相当吊。

  至于怎么简化,这里大概做一下解释,原文中的解释更加详细和有趣。
  首先,SQL语句是这么写的:SELECT * FROM TestRecompile WHERE Id = @p_parameter OR @p_parameter IS NULL
  当“植入参数”之后,也即上文中使用的@p_parameter = 123456,SQL语句变成了SELECT * FROM TestRecompile WHERE Id = 12345 OR 12345 IS NULL
  因为OR 12345 IS NULL是永远不成立的,甚至可以认为是将SQL语句直接简化成了SELECT * FROM TestRecompile WHERE Id = 12345 ,这样子的话,在当前情况下,肯定是可以用到索引的。
  因此,OPTION(RECOMPILE)强制重编译的SQL在编译并且简化之后,就变成了如下的SQL,这里解释还是感觉有点牵强的,没有原文有说服力。

  

  那么再回头看WITH RECOMPILE强制重编译,WITH RECOMPILE强制重编译的时候,没有能够做到OPTION(RECOMPILE)强制重编译中的“解析器神奇地把复杂的问题简化”
  参考这个链接:http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/
  对于类似WHERE Id = @p_parameter OR @p_parameter IS NULL这种查询方式,

  上述文章中是这么解释的:
  The problem with these types of queries is that there is no stable plan.
  The optimal plan differs completely depending on what paramters are passed.
  The optimiser can tell that and it plays safe. It creates plans that will always work. That’s (one of the reasons) why in the first example it was an index scan, not an index seek.
  翻译过来大概意思就是:
  这种类型的查询问题在于没有固定的执行计划,
  优化方案是基于具体传入进来的参数值的,
  优化器只能做到保证安全性(plays safe),他创建的执行计划确保总是可以正常工作的。

  我这里补充解释一下 it plays safe在我的理解:
  如果@p_parameter 参数非空,走索引Seek完全没有问题。
    如果@p_parameter 为null,此时and (Id= @p_parameter or @p_parameter is null )这个条件恒成立,如果再走索引Seek会出现什么结果?
    如果继续采用Index Seek的方式执行,语义上变成了是查找Id为null的值,这样的话逻辑上已经错误了。
  因此出现这种写法,为了安全起见(上文所谓的plays safe),优化器只能选择一个这种的索引的扫描的方案(所谓的always work的执行计划)

  关于OPTION(RECOMPILE)在SQL语句级重编译神奇的魔力,他会根据具体的参数做到真正的重编译,我们在做一个测试:
  这一次设置@p_parameter = null,看看是不是又重新编译了一个合理的执行计划,没错,这次它生成了一个全表扫描的执行计划,也是没有问题的。
  唯一有瑕疵的地方时,相对WITH RECOMPILE强制重编译的方式,他的执行计划没有用到并行。这也是WITH RECOMPILE和OPTION(RECOMPILE)两种强制重编译生成执行计划的区别
  但是不能否认OPTION(RECOMPILE)强制重编译中的Parameter Embedding Optimization这种优化机制的特性

  

  而此时WITH RECOMPILE强制重编译方式的执行计划,在传入参数值为null的时候,生成的是并行的执行计划

  

现在来解释为什么非常强烈不建议写这种SQL:SELECT * FROM TestRecompile WHERE Id = @p_parameter OR @p_parameter IS NULL

  我在之前也写过http://www.cnblogs.com/wy123/p/5958047.html,感觉没有彻底解释清楚索引抑制问题的原因。

  开发中常见的一个潜在的多个条件的查询SQL,具体的查询条件是依赖于用户输入的,
  比如提供给用户三个查询条件可选的查询条件,用户可以输入一个,两个或者三个,这个太常见了,也不用再解释了
  那么我们就要构造出适应这种查询的一种方案
  面对这种catch-all-queries的查询方式,其中方案之一就是类似于这种写法
  SELECT * FROM TestRecompile
  WHERE (parameter1 = @p_parameter1 OR @p_parameter1 IS NULL)
    and (parameter2 = @p_parameter2 OR @p_parameter2 IS NULL)
    and (parameter3 = @p_parameter3 OR @p_parameter3 IS NULL)
  这种最大的问题就是在查询列上有索引,且查询列上接收到的输入参数非空的时候,是会抑制到索引的使用的
  上文中演示了,虽然用到了Id 列上的索引,采用的是INDEX SCAN,比全表扫描(TABLE SCAN)强一点点,他跟真正用到INDEX SEEK在效率上讲,完全是两码事,
  所以我们在开发的过程中强烈不建议使用 Id = @p_parameter OR @p_parameter IS NULL这种写法,
  当然,在不考虑parameter sinffing问题的时候,我们首选参数化动态SQL,即便是非参数化动态SQL(EXEC的方式执行一个拼凑出来的字符串),也比Id = @p_parameter OR @p_parameter IS NULL这种方式好
  如果有人进一步问:为什么查询条件中Id = @p_parameter OR @p_parameter IS NULL这种写法会抑制到索引的使用,真的是一个很难解释清楚的问题,解释不清楚也是一件很尴尬的事。
  这种逻辑之所以抑制到索引的最优化使用,真如上文分析的,优化器没有真正的用到INDEX SEEK,是为了安全起见(上文所谓的plays safe)考虑
  说道到这里我又开始凌乱了,也就是WITH RECOMPILE和OPTION(RECOMPILE)这两种方式的造强制,有一种只可意会不可言传的感觉。
  这就是即便是编译的过程中知道具体的参数值,也做到编译出来INDEX SEEK的执行计划的原因
  总是我在http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/这里找到了跟我对该问题理解的相似的解释,也算释怀了

如果准确地预估表变量

  与with recompile相比,option(recompile)选项可以地预估表变量的行数,再次说明option(recompile)是基于参数置入(Parameter Embedding Optimization)编译的特性

  直接看例子吧,应该是很清楚的

  with recompile情况下对表变量的预估,

  简单解释一下,就是在存储过程中,with recompile强制存储过程重编译的情况下,表变量参数join的时候,对表变量的预估情况如下

  

  option(recompile)强制存储过程重编译的情况下,表变量参数join的时候,对表变量的预估情况如下

  可见,option(recompile)强制重编译,不但可以获取与with recompile重编译不一样的执行计划,也可以非常准确地预估到表变量的行数

  可以解决默认情况下,表变量总是预估为1行的情况(应该是sqlserver 2012之后有改善,sqlserver 2012之前默认预估为1行)

  

总结:本文通过一个简单的案例,解释了WITH RECOMPILE和OPTION(RECOMPILE)这种强制重编译方式的区别,以及引申出来的The Parameter Embedding Optimization(第一次听说)优化机制。
   很多时候,自己对一些知识只是想当然地去理解和使用,比如随意使用WITH RECOMPILE和OPTION(RECOMPILE),
   粗暴地认为这两种强制重编译的方式区别仅仅在于一个是存储过程级的重编译,一个是SQL语句级的重编译。真正拿着case测试的时候,才发现,还真不一样。

下一篇写一个跟这个机制类似的同样有意思的文章。

参考资料:https://sqlperformance.com/2013/08/t-sql-queries/parameter-sniffing-embedding-and-the-recompile-options

     http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/

       http://www.sommarskog.se/dyn-search-2008.html

     同时,再次感谢Uest同学提供的参考资料和指导建议。

WITH RECOMPILE和OPTION(RECOMPILE)区别的更多相关文章

  1. 关于T-SQL重编译那点事,WITH RECOMPILE和OPTION(RECOMPILE)区别仅仅是存储过程级重编译和SQL语句级重编译吗

    本文出处:http://www.cnblogs.com/wy123/p/6262800.html   在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的 ...

  2. WITH RECOMPILE和OPTION(RECOMPILE)区别仅仅是存储过程级重编译和SQL语句级重编译吗

    在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的其他因素的情况下,比如重建索引,更新统计信息等等), 一是基于WITH RECOMPILE的存储过程级 ...

  3. WITH RECOMPILE 和 OPTION(RECOMPILE) 使用上的区别

    在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的其他因素的情况下,比如重建索引,更新统计信息等等), 一是基于WITH RECOMPILE的存储过程级 ...

  4. option(recompile)

    Ref: http://www.cnblogs.com/CareySon/archive/2013/05/04/PlanCacheInSQLServerPart2.html https://msdn. ...

  5. 关于T-SQL重编译那点事,内联函数和表值函数在编译生成执行计划的区别

    本文出处:http://www.cnblogs.com/wy123/p/6266724.html 最近在学习 WITH RECOMPILE和OPTION(RECOMPILE)在重编译上的区别的时候,无 ...

  6. SQLServer中的执行计划缓存由于长时间缓存对性能造成的干扰

    本文出处:http://www.cnblogs.com/wy123/p/7190785.html (保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错 ...

  7. SQL Server-聚焦什么时候用OPTION(COMPILE)呢?

    前言 上一篇我们探讨了在静态语句中使用WHERE Column = @Param OR @Param IS NULL的问题,有对OPTION(COMPILE)的评论,那这节我们来探讨OPTION(CO ...

  8. JS & JQuery 动态添加 select option

    因为是转载文章 在此标明出处,以前有文章是转的没标明的请谅解,因为有些已经无法找到出处,或者与其它原因. 如有冒犯请联系本人,或删除,或标明出处. 因为好的文章,以前只想收藏,但连接有时候会失效,所以 ...

  9. JS & JQuery 动态处理select option

    原文 出处http://www.51xuediannao.com/html+css/htmlcssjq/cssbuhuanhang.html 今天你问了我一个关于在<select>里动态添 ...

随机推荐

  1. 【FZSZ2017暑假提高组Day1】确定小组

    [问题描述] 有n个人坐成一排,这n个人都在某一个小组中,同一个小组的所有人所坐的位置一定是连续的. 有一个记者在现场进行采访,他每次采访都会询问一个人其所在的小组有多少人,被询问的每个人都给出了正确 ...

  2. git的简单命令

    git pull 拉下最新版本. git add . git commit 输入提交信息 esc返回 :wq保存 git push .git保存着当前仓库的信息.git bash here的时候,要确 ...

  3. 为datagrid、treegrid增加右键表头菜单,用于显示或隐藏列,注意:冻结列不在此菜单中

    var createGridHeaderContextMenu = function(e, field) { e.preventDefault(); var grid = $(this);/* gri ...

  4. get_time

    def get_current_time(): #将python的datetime转换为unix时间戳 dtime = datetime.datetime.now() un_time = time.m ...

  5. DRF的解析器和渲染器

    解析器 解析器的作用 解析器的作用就是服务端接收客户端传过来的数据,把数据解析成自己可以处理的数据.本质就是对请求体中的数据进行解析. 在了解解析器之前,我们要先知道Accept以及ContentTy ...

  6. Poiji:基于列名绑定方式将Excel单元行转换为JavaBean的开源框架

    公司的日常事务中经常需要使用excel进行数据汇总,导入导出进行归类统计分析. 因为没有广泛流行的单元行到类转换/属性绑定工具,在功能开发之初或者很长一段时间内, 业务系统中我们处理普通excel数据 ...

  7. 32.Mysql Cluster

    32.Mysql Cluster Cluster是一组节点的组合.节点分为数据节点.SQL节点.管理节点.节点组合在一起可以为应用提供高可用.高性能.可缩放的Cluster数据管理.数据节点使用NDB ...

  8. 将VSCode设置成中文语言环境

    VSCode是一款轻量级的好用的编译软件,今天小编来将软件默认的英文语言环境变为我们熟悉的中文语言环境. 工具/原料   电脑一台 安装有VSCode 方法/步骤     首先打开VSCode软件,可 ...

  9. 17. pt-online-schema-change

    在平时MySQL的运维过程中,经常会遇到表结构的变更.在表比较小的时候,直接进行变更,时间较短,但是当表非常大的时候,这么做会导致应用卡死,服务不可用.目前InnoDB引擎是通过以下步骤来进行DDL的 ...

  10. tar: Removing leading `/' from member names

    解决办法使用 -P 参数 注意 -f 参数后面跟压缩后的文件名