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