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