数据库参数化的模式
数据库的参数化有两种方式，简单（simple）和强制（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
