环境：SQL Server2012 SP3 企业版，开发服务器，并没有什么负载，全库索引统一Rebuild过

经反复执行验证过，

不算太复杂的SQL（存储过程中代入参数抠出来的SQL代码）

　默认情况下，执行完成需要3秒钟

　非要用红色圈中子查询中的表（是一个相关子查询）去驱动其他表，

　添加OPTION(FORCE ORDER)后，强制连接顺序，用其他表驱动子查询，1秒钟

　　默认情况下：

　　　　　　　　IO消耗的比较少（相比强制驱动顺序），但是CPU消耗的比较多，但是整体时间的消耗比强制驱动顺序要多

　　强制表的驱动顺序的时候：

　　　　　　　　IO比默认情况下要多（相比默认情况下），但是，CPU消耗的比较少，整体上耗时较短

后记：

　　我一直就怀疑一个问题，SQL Server内部评估执行计划的时候，IO的权重要比其他的资源权重要大，

　　不止一次两次遇到类似问题了，

　　总结起来发现一个规律：

　　SQL Server总是“喜欢”选择IO较小的执行方式去完成一个查询，但是这个查询方式，从时间上看，并不一定是最快的

　　虽然这里没有用某个例子证明Exists的使用“没问题”或者“有问题”，但面对情况往往比较复杂的时候，

　　Exists子查询往往会引起意料之外的执行方式（执行计划），越来越怕Exists子查询了，像定时炸弹一样，不知道什么时候爆发

　　说Exists子查询会引起某些问题，而又没有佐证，面对主观意识比较强的人，可能会不高兴，

　　当然可以有人会拿出来100个case来证明exists子查询没有问题，但是我想说，遇到性能问题，还是注意点这个Exists子查询，

　　也是不止一次遇到它引起的问题了