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