您好,登錄后才能下訂單哦!
這篇文章將為大家詳細(xì)講解有關(guān)sql連接查詢語句中on、where篩選的區(qū)別是什么,小編覺得挺實(shí)用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
來看一個示例,有兩張數(shù)據(jù)表,結(jié)構(gòu)和數(shù)據(jù)如圖所示
表main
表ext
可以把這兩張表看作是用來存放用戶信息的, main放置主要信息,ext表放置附加信息,兩張表的關(guān)系是1對1的,以id字符作為對應(yīng)關(guān)系鍵?,F(xiàn)在我們需要將地址不為杭州的所有用戶信息篩選出來,結(jié)果中需要包含main表和ext表的所有字段數(shù)據(jù)。
select * from main left JOIN exton main.id = ext.id and address <> '杭州'
閉上眼睛, 請用大腦人肉運(yùn)行一下這段SQL, 想象一下是什么結(jié)果。
當(dāng)把address <> '杭州'
這個篩選條件放在on之后,查詢得到的結(jié)果似乎跟我們預(yù)料中的不同,從結(jié)果中能看出,這個篩選條件好像只過濾掉了ext表中對應(yīng)的記錄,而main表中的記錄并沒有被過濾掉,也就是上圖中標(biāo)記為紅色的那條記錄。outer join
相對于inner join
的一個主要特性就是以一側(cè)的表為基礎(chǔ),但是在這里以左表為基這一點(diǎn)卻可以無視篩選條件,這未免也太霸道了一些。
把查詢語句稍微改動一下,將地址的篩選條件從on轉(zhuǎn)移至where
select * from main left JOIN ext on main.id = ext.id where address <> '杭州'
結(jié)果就如我們預(yù)期的那樣了
造成這種結(jié)果上的差異要從outer join
查詢的邏輯查詢的各個階段說起。
總的來說,outer join 的執(zhí)行過程分為4步
1、先對兩個表執(zhí)行交叉連接(笛卡爾積)
2、應(yīng)用on篩選器
3、添加外部行
4、應(yīng)用where篩選器
就拿上面不使用where篩選器的sql來說,執(zhí)行的整個詳細(xì)過程如下
第一步,對兩個表執(zhí)行交叉連接,結(jié)果如下,這一步會產(chǎn)生36條記錄(此圖顯示不全)
第二步,應(yīng)用on篩選器。篩選器中有兩個條件,main.id = ext.id and address<> '杭州'
,符合要求的記錄如下
這似乎正是我們期望中查詢的結(jié)果,然而在接下來的步驟中這個結(jié)果會被打亂
第三步,添加外部行。outer join
有一個特點(diǎn)就是以一側(cè)的表為基,假如另一側(cè)的表沒有符合on篩選條件的記錄,則以null替代。在這次的查詢中,這一步的作用就是將那條原本應(yīng)該被過濾掉的記錄給添加了回來
是不是不種畫蛇添足的感覺, 結(jié)果就成了這樣
第四步,應(yīng)用where篩選器
在這條問題sql中,因?yàn)闆]有where篩選器,所以上一步的結(jié)果就是最終的結(jié)果了。
而對于那條地址篩選在where條件中的sql,這一步便起到了作用,將所有地址不屬于杭州的記錄篩選了出來
通過上面的講解,已經(jīng)能反應(yīng)出在outer join
中的篩選條件在on中和where中的區(qū)別,開發(fā)人員如能詳細(xì)了解之中差別,能規(guī)避很多在編寫sql過程中出現(xiàn)的莫名其妙的錯誤。
關(guān)于“sql連接查詢語句中on、where篩選的區(qū)別是什么”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,使各位可以學(xué)到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。