本文將討論的是SQL中簡(jiǎn)單嵌套查詢與非嵌套查詢的異同，通過(guò)這些來(lái)更加深刻理解SQL語(yǔ)句。

創(chuàng)新互聯(lián)公司專注于天水企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)。天水網(wǎng)站建設(shè)公司,為天水等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站策劃，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

某天的工作是修復(fù)某個(gè)項(xiàng)目的bug，接著就發(fā)現(xiàn)，其sql極其混亂，有非常多的left join和in操作，還有嵌套查詢（只有一個(gè)表的嵌套查詢）。不知道看到過(guò)哪里的資料說(shuō)，嵌套查詢速度慢，于是我把全部嵌套查詢都改成join的形式，嵌套查詢里面的where條件，我都寫到j(luò)oin...on后面去了。突然一個(gè)想法冒出來(lái)：篩選條件跟在join...on后面 和 跟在整個(gè)sql語(yǔ)句***面的where后面有什么區(qū)別呢？還有嵌套查詢真的慢么？于是便有下面的測(cè)試產(chǎn)生，數(shù)據(jù)庫(kù)環(huán)境為MS SQL 2005。

一，inner join

先看看非嵌套查詢：

 
 
 
 

  
  
  
  
a.select * from t1 
  
  
  
  
inner join t2 on t1.id = t2.id 
  
  
  
  
inner join t3 on t1.id = t3.id 
  
  
  
  
where t1.a=1 and t2.b=1 and t3.c=1 
  
  
  
  

  
  
  
  
b.select * from t1 
  
  
  
  
inner join t2 on t1.id = t2.id and t2.b=1  
  
  
  
  
inner join t3 on t1.id = t3.id 
  
  
  
  
where t1.a=1 and t3.c=1 
  
  
  
  

  
  
  
  
c.select * from t1 
  
  
  
  
inner join t2 on t1.id = t2.id and t2.b=1  
  
  
  
  
inner join t3 on t1.id = t3.id and t3.c=1 
  
  
  
  
where t1.a=1
 
 
 
 

在上面三個(gè)非嵌套查詢，讓“and t2.b=1”和“and t3.c=1”分別在join...on和where之間游走，用Management Studio選中“包含實(shí)際的執(zhí)行計(jì)劃”并執(zhí)行這三條語(yǔ)句，都得出下面這個(gè)執(zhí)行計(jì)劃。

三個(gè)“聚集索引掃描”的謂詞從上到下分別是：

1.t3.c=1

2.t1.a=1 (seek謂詞：t1.id=t3.id)

3.t2.b=1 (seek謂詞：t2.id=t3.id)

故可以認(rèn)為：在MS SQL2005中，條件跟在join...on后面 和 跟在where后面是等價(jià)的。

接著看嵌套查詢：

 
 
 
 

  
  
  
  
d.select * from t1 
  
  
  
  
inner join (select * from t2 where t2.b=1)a on t1.id=a.id 
  
  
  
  
inner join t3 on t1.id = t3.id 
  
  
  
  
where t1.a=1 and t3.c=1 
  
  
  
  

  
  
  
  
e.select * from t1 
  
  
  
  
inner join (select * from t2 where t2.b=1)a on t1.id=a.id 
  
  
  
  
inner join (select * from t3 where t3.c=1)b on t1.id=b.id 
  
  
  
  
where t1.a=1 
  
  
  
  

  
  
  
  
f.elect * from t1 
  
  
  
  
inner join (select t3.id,t2.b,t3.c from t3 inner join t2 on t2.id = t3.id where t2.b=1 and t3.c=1)a on t1.id=a.id 
  
  
  
  
where t1.a=1
 
 
 
 

***句sql語(yǔ)句把t2的查詢變成子查詢，第二句sql語(yǔ)句把t2,t3分別變成子查詢，第三句把t2和t3的查詢合成一個(gè)子查詢，再看看實(shí)際的執(zhí)行計(jì)劃：

跟上面非嵌套查詢的執(zhí)行計(jì)劃一模一樣。

故可以認(rèn)為：簡(jiǎn)單（注意是簡(jiǎn)單的，復(fù)雜的情況得另外考慮）嵌套查詢和其相對(duì)應(yīng)的非嵌套查詢形式，執(zhí)行效率是一樣的（網(wǎng)上一些文章指出這是MS SQL優(yōu)化器針對(duì)這些嵌套查詢進(jìn)行了優(yōu)化）。

接著，在上面兩個(gè)執(zhí)行計(jì)劃的圖中又發(fā)現(xiàn)一個(gè)小問題，為什么明明是select t1 inner join t2 inner join t3，執(zhí)行計(jì)劃卻把t1和t3先inner join(t1.id = t3.id)再跟t2 inner join（t2.id = t3.id）起來(lái)？

經(jīng)過(guò)三個(gè)表，四個(gè)表，五個(gè)表進(jìn)行連接測(cè)試，發(fā)現(xiàn)這些順序都是不確定的。很可能這些順序是根據(jù)SQL優(yōu)化器內(nèi)的算法所決定的，由于沒有源代碼，所以無(wú)從考究。

(感謝Keep Walking的補(bǔ)充:

“可以指定順序，force order選項(xiàng)，和keep plan選項(xiàng)

數(shù)量級(jí)，索引，統(tǒng)計(jì)的不同都可以導(dǎo)致順序變化”。
我Google了一下option force order和option keep plan，發(fā)現(xiàn)SQL優(yōu)化器做了很多事情，在這文章就不列出來(lái)了，大家有興趣可以Goo一下。)

PS：

1.經(jīng)測(cè)試，在join on后面t1.id = t2.id與t2.id = t1.id等價(jià)

如果發(fā)現(xiàn)這文章有錯(cuò)誤，歡迎指出。

鏈接：http://www.cnblogs.com/StephenHuang/archive/2010/01/03/1637846.html

文章題目：對(duì)比SQL中簡(jiǎn)單嵌套查詢與非嵌套查詢的異同
網(wǎng)頁(yè)網(wǎng)址：http://uogjgqi.cn/article/cocdioj.html