自动参数化存在的问题
　　自动参数化好处并不用多说，因为可以重用缓存的执行计划，避免了每次参数值不一样重编译的问题。说到执行计划重用，不得不说的一个话题是parameter sniff，嘴皮子都磨破的问题了
　　没错，自动参数化因为不同参数会重用第一次编译生成的执行计划，很有可能造成parameter sniff问题，以及parameter sniff衍生出来的其他问题
　　同样用一个例子来做演示，该问题是近在观察执行计划统计信息（statistics）预估问题时遇到的一个问题，让我困惑了好一会，这里再次感谢潇湘隐者。
　　该问题同样也是因为自动参数化了SQL语句，造成执行计划重用，从而造成一个极其简单的SQL执行效率在某些情况下较低的情况，为什么自动化参数的原因跟上述类似，都是有且只有一种执行方式（索引查找）的情况下，不同参数执行计划重用造成对数据行的错误预估。测试之前清空一下缓存执行计划，观察不同查询条件下的实际执行计划对数据行的预估
　　如下查询条件：
　　1，初始查询条件为：CreateDate>’2016-6-1′ and CreateDate

　　2，将查询条件更新为：CreateDate>’2016-6-1′ and CreateDate

　　3，将查询条件更新为：CreateDate>’2016-6-1′ and CreateDate

　　发现没有，因为查询时间段有变化，实际行数也有变化，但是不管实际行数多少，预估行数总是为第一次执行预估的行数。
　　这肯定不对吧？随便带入什么条件，预估行数都是37117，当时一下子蒙了，怎么每次执行SQL对数据行的预估都是一样的？
　　其实这个问题跟一开始举例的一样，都是SQL语句被自动参数化了，因此造成了执行计划重用，执行计划重用，导致错误地预估实际查询的数据行数。
　　如何解决自动参数化造成错误地重用执行计划的问题？
　　很多问题找到了真正的原因，解决起来往往并不难，这个问题的原因是执行计划重用造成的，那么我们只需要解决执行计划重用的问题即可。也是不让他重用执行计划，只需要在SQL语句中加一个提示即可，也即：select COUNT(1) from Test20160810 where CreateDate>’2016-6-1′ and CreateDateOPTION(RECOMPILE)
　　原因在于加上OPTION(RECOMPILE)这个查询提示之后，不缓存SQL的执行计划缓存，没有了执行计划缓存，也没得重用了
　　比如这个查询，在查询语句中加入OPTION(RECOMPILE)查询提示，让其执行之前重编译SQL语句，他可以正确地预估数据行了。

　　总结
　　本文通过一个实际案例说明了什么是简单参数模式下的自动化参数，自动化参数会带来哪些问题，以及如何解决，问题本身非常简单，如果不注意还是会偶尔还是会出现困惑的。
　　题外话
　　有一点感受非常深，是说，越来越多的实际问题，都要有理论知识作支撑，但往往理论上说的情况并没有频繁出现或者即使出现了也没有引起注意，有时间忽略了一些理论上的知识。
　　对于遇到的问题，如果真的要想弄清楚，还是要有一些理论知识做铺垫的。很多时候，往往是遇到问题之后，回忆起来曾经好似乎看过这一方面的理论知识。这也是我们需要坚持看书，了解一些理论知识的原因。