本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列
在工作中发现有不少类似的现象，有幸看到国外大牛写的一篇文章，由于已经完善得不能再添油加醋，所以决定直接翻译，原文出处：http://www.sommarskog.se/query-plan-mysteries.html#defaultsettings 本人水平有限，如果读者觉得自己英语过得去，建议阅读原文。在翻译过程中，不排除会对某些部分进行修改，但不会影响最终效果。
由于内容较多，所以把文章拆为多篇发布，本系列文章结构：
简介：
我逛了很多论坛之后，发现有一个常见的问题：提问者已经定位一个应用程序中的低效查询或存储过程，然后把它放到SSMS（SQL Server Management Studio）中执行和分析时，却发现瞬间执行完毕。他们为此觉得SQL Server很神奇，百思不得其解。同时，开发人员也可能遇到这种情况，存储过程中的某个语句抓出来单独运行时，可能比在存储过程中慢/快很多。
当然，把这个现象当作奇怪现象甚至BUG是不合理的。但是如果你不清楚SQL Server是如何编译查询和维护其执行计划缓存的话，看起来确实很难解释。而且一些不同环境中的不同配置也会触发这种奇怪的现象。所以在本文中，我（作者）尽量整理和解释这种看上去很难解释的行为。文中会介绍SQL Server如何编译一个存储过程、什么是参数嗅探并且说明为什么它会导致这种让人迷惑的现象。另外我也会解释SQL Server如何使用缓存、为什么缓存中的一个存储过程会有很多词目（entries）。在了解了这些之后，你就明白会什么在SSMS中执行起来比应用程序中快得多。
另外为了理解如何定位应用程序中的性能问题，也有必要继续看下去。但是先不马上进入参数嗅探的话题，先介绍一些其他影响性能的情景。 然后接下来的两节会介绍关于参数嗅探导致的性能问题。第一部分是手机信息。第二部分是在现实情况和通用情况下的一些可能出现的问题。在最后一部分，讨论SQL Server如何编译动态SQL和如何域计划缓存交互。最后是一些相关方面的微软白皮书资料。
假定：
本质上，这系列文章适用于所有版本的SQL Server，但是由于从SQL 2005之后SQL Server有了重大改进，所以这里关注于SQL 2005及以后版本。本系列包含一些检索计划缓存的语句，这些语句仅在SQL 2005及后续版本可用，同时需要服务器级别的VIEW SERVER STATE权限。
本系列不是入门级课题，读者应该有一定的SQL 编程 经验。你不需要精通性能优化，但是有则更好。因为有些内容没办法在这里做深入介绍，毕竟本系列不是教科书。不是介绍如何优化所有性能问题，但是最起码可以作为一个开端。
警告：本系列部分地方会使用在线联机丛书链接，可能会出现部分版本不符合的情况，尽可能选择自己使用的版本的内容阅读。
