环境：
Sql Server2012 SP3企业版，Windows Server2008 标准版
问题由来：
最近在做DB优化的时候，发现一个存储过程有非常严重的性能问题，
由于整个SP整体逻辑是一个多表关联的复杂的查询，整体结构比较复杂的，通过的分析和尝试，
最后发现问题出在其中一个大表的查询上实现方式上，
因为这个大表上的意外的执行方式，导致其他表无法被驱动，其他表也是表扫描的方式参与join
导致后面整个表之间join以及查询编译出来一系列极其低效的执行效果（不合理的执行计划）
这里单独将这个大表的查询提取出来作分析
下面就是我说的大表的这一步在默认情况下的执行情况，
这个表当时数据量是3000W条，符合查询条件的数据在50W左右(一个月的数据量)，
不加索引提示下的执行情况（测试之前都DBCC dropcleanbuffer 清理缓存）：
因为考虑到结果集比较大，SSMS结果窗口加载数据耗时比较长
我将结果Insert到临时表的目的是减少SSMS加载数据的时间，更注重查询内部计算
如下是sql查询执行信息
执行计划情况
可以看到它走了一个跟查询字段无关的普通索引的index scan的执行计划，
加上索引提示的执行情况：
如果加一个查询列上的索引的查询提示，会发现性能上有一个比较明显的提升
当加上查询索引提示之后，2s中就完成了，比上面默认没有索引提示的方式提高了4倍
执行计划信息
这里就有一个问题，默认情况下为什么没有采用索引查找的方式，而采用了全表扫描的方式？
如果没猜错的话，很可能有人跟我一样，是认为统计信息没有更新，索引碎片之类导致的
这个查询非常简单，到底是不是索引统计信息，或者索引碎片之类的引起的呢？
这个倒是好办，对这个表上的所有索引全部重建（rebuild），同时也会促使统计信息的更新。
然后继续测试，问题依旧！！！
基本上可以认为，外界条件没有额外干扰的情况下，Sql Server 始终没有选择一个执行速度较快的执行计划，
之所以说Sql Server没有选择执行速度较快的执行计划，而不是说最优的，是因为这个执行计划是没办法直接去评判的，
如果你注意的话，会发现：
不加索引提示的时候：逻辑读是：589689，物理读是589723
加了索引提示的时候，逻辑读是：1992328，但是真正的物理读并不多，只有11229+2042
逻辑读的增加是在内存中作计算的时候产生的
但是这并不影响后者执行时间更短，
因为后者还有一个内存授予（Memory Grant）一个211M的物理内存用来暂存中间结果集来以更高效的方式来执行
所以我前面说Sqlserver没有选择“执行速度较快”的执行计划，而不是说最优化的执行计划，
因为后者执行更快，但是耗费了更多的服务器资源，前者执行较慢，但是没有耗费很多系统资源。
最优化的是一个很难用一棒子打死的方式去界定的，到底是以执行时间为评判，还是以资源消耗为评判？
我想sqlserver是以综合考量去评价的吧，出现这种情况，我只能推断：默认情况下，评估执行计划的时候，IO的系数在计算中的权重更大
如果服务器资源充足的情况下：
肯定宁愿为其提供充足资源去让其更快地执行以相应应用程序的请求
如果服务器资源不够充足的情况下：
这个SQl的运行需要这么多内存，
可能就需要为了申请到（比第一种执行方式）足够多的内存而造成更长时间的等待（这里不细说，比如memory grants pending）
此时，还不如让他慢慢执行，好歹还能跑出来结果。
这种究竟哪种方式好，哪种方式不好，很难有一个定论，一切都要根据具体情况来定，
数据库自身不太可能在任何情况下都作出最最明智的选择，这大概也就是各种关系数据库预留给用户一些查询提示的原因吧。
总结：
以上粗浅地根据一个遇到的实例案例，通过认为改变默认情况下的执行计划来观察对比sql的执行效率，在我们对数据库进行性能调优时提供一种可参考的方法
也能够帮助我们认识Sql Server在选择执行计划时候的一些特点，以帮助我们更加有效地使用Sql Server数据库。
