环境：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子查询，
也是不止一次遇到它引起的问题了