表中討論了決定性能權衡的某些問題，以及傾向于哪一中解決方案
|
情況
|
傾向于
|
|
從子查詢中返回的數值對于外部查詢中的所有行是相同的
|
預查詢。聲明變量，然后選擇需要的值放入變量中，這能使即將形成的子查詢只執行一次，而不是對外部表中的每一條記錄執行一次。事實上SQL Server中的優化器相當聰明，它一旦察覺到處于這樣的情形，將為你進行預查詢，但是別依賴它。為了以防萬一，當你意識到這樣的情形時，請執行你自己的預查詢。
|
|
兩個表都相對較小（例如：只有10 000條記錄或者更少）
|
子查詢。我不清楚確切的原因是什么，，但是，關于這一點我已經做過多次實驗，幾乎每次都能得到這樣的結果。我懷疑是由于，當所有的查找數據僅僅屬于一、兩個數據頁時，查找比起聯結花費的開銷更少。
|
|
在考慮了所有的條件后，匹配將只返回一個值
|
子查詢。同樣，比起必須聯結整張表來說，只找尋一條記錄并代換它所需的開銷要少得多。
|
|
在考慮了所有的條件后，匹配將只返回相對較少的值，并且，在查找列上沒有索引
|
子查詢。通常，比起散列聯結來說，單獨的一次或者甚至數次查找將花費較少的開銷。
|
|
查找表相對較小，基表很大
|
若可以的話，則使用嵌套子查詢；若聯結相對于相關子查詢，則使用聯結。使用子查詢時，查找只發生一次，因而其開銷相對較小。然而，如果使用的是相關子查詢，則查找將會循環許多次-----既如此，大多數情況此案聯結將是更好的選擇。
|
|
相關子查詢與聯結
|
聯結。本質上，相關子查詢將造成嵌套循環的情形。這會產生相當多的開銷。多數情況下，他遠遠快于游標，但是，它比其他可能的選擇方案要慢一些。
|
|
派生表與其他選擇
|
派生表常常意味著大量的開銷，因此需要謹慎使用。要知道，派生表只運行一次，隨后就會駐留與內存中，因而，多數的開銷存在于首次創建的過程中以及沒有索引的較大結果集上。它們可能很快、也可能很慢，這取決于具體的情況。在進行編寫派生表前要仔細考慮。
|
|
EXISTS與其他選擇
|
EXISTS。不必針對同樣的條件進行多次查找------但找到了特定行的一個匹配，將進入到下一個查找中，這能夠極大地減少開銷。
|