環境：SQL Server2012 SP3 企業版，開發伺服器，並沒有什麼負載，全庫索引統一Rebuild過 經反覆執行驗證過， 不算太複雜的SQL（存儲過程中代入參數摳出來的SQL代碼） 預設情況下，執行完成需要3秒鐘 非要用紅色圈中子查詢中的表（是一個相關子查詢）去驅動其他表， 添加OPTION ...
環境：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子查詢，
也是不止一次遇到它引起的問題了
