点击上方“蓝字”可以关注我们哦 |转载自：cnblog |原文链接：http://www.cnblogs.com/wy123/p/5757902.html 数据库参数化的模式 数据库的参数化有两种方式，简单（**）和强制（forced），默认的参数化默认是“简单”，简单模式下，如果每次发过来的SQL，除非完全一样，否则就重编译它（特殊情况会自动参数化，正是本文想说的重点） 强制模式就是将adhoc SQL强制参数化，避免每次运行的时候因为参数值的不同而重编译，这里不详细说明。 这首先要感谢“潇湘隐者”大神的提示，当时也是遇到一个实际问题，发现执行计划对数据行的预估，怎么都不对，有观察到无论怎么改变参数，SQL语句执行前都没有重编译，疑惑了好一会，这个问题正是简单参数化模式下，对某些SQL自动参数化造成执行计划重用引起的，也是本文想表达的重点。 这个问题之前就写过，当时也只是看书上理论上这么说的，没有想到其带来的影响，该参数是一个数据级别的选项，设置情况可以参考下图 什么情况下会自动参数化 简单参数化模式下，对于有且只有一种执行方式的Adhoc SQL语句，SQL Server会自动参数化它，从而达到重用执行计划的目的。 究竟哪些类型的SQL会被自动参数化，后面会举例说明。 自动参数化会存在哪些问题 在简单模式下，SQL对于某些SQL会自动参数化他，避免每次都重编译。 SQL Server 自动参数化SQL语句的行为，能够避免一些重编译，原本也是出于“好意”，但是这种“好意”往往不一定总是给我们带来好处。 举例说明什么情况下会自动参数化 先造一个简单的测试环境 create table TestAuotParameter ( id int not null, col2 varchar(50) ) GO declare @i int=0 while @i100000 begin insert into TestAuotParameter values (@i, NEWID()) set @i=@i 1 end GO create unique index idx_id on TestAuotParameter(id) GO 之所以自动参数化了SQL语句，就是因为select * from TestAuotParameter where id=33333 （66666,99999）这句SQL语句，在当前的数据量下和唯一索引的特点，决定了有且只有一种高效的执行方式（也就是索引查找）这里说有且只有一种方式是表中数据量相对较多，又因为idx_id这个索引是unique的。如果不是unique的，那么情况就不同了，下面来解释什么是有且只有一种高效的执行计划 如下截图：同样的测试，我删除id上的唯一索引，创建为非唯一索引，再做同样的测试，就会发现执行同样的SQL并没有被自动参数化 这里解释一下原因，索引类型怎么跟执行计划缓存扯上了？ 对于非唯一索引，有可能作做引查找是高效的，有可能做全表扫描是高效的（比如某个ID的数据分布的特别多）此时执行计划有可能是多样的，不仅仅只有一种方式，所以就不会自动参数化SQL 自动参数化存在的问题 自动参数化好处并不用多说，因为可以重用缓存的执行计划，避免了每次参数值不一样就重编译的问题。说到执行计划重用，不得不说的一个话题就是parameter sniff，嘴皮子都磨破的问题了 没错，自动参数化因为不同参数会重用第一次编译生成的执行计划，很有可能造成parameter sniff问题，以及parameter sniff衍生出来的其他问题 同样用一个例子来做演示，该问题是最近在观察执行计划统计信息（statistics）预估问题时遇到的一个问题，让我困惑了好一会，这里再次感谢潇湘隐者。 该问题同样也是因为自动参数化了SQL语句，造成执行计划重用，从而造成一个极其简单的SQL执行效率在某些情况下较低的情况，为什么自动化参数的原因跟上述类似，都是有且只有一种执行方式（索引查找）的情况下，不同参数执行计划重用造成对数据行的错误预估。测试之前清空一下缓存执行计划，观察不同查询条件下的实际执行计划对数据行的预估 如下查询条件： 1，初始查询条件为：CreateDate |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
