這一系列講述，兩張表的 Join, 或許你都不一定知道的事兒。

之前寫過 SQL 的編譯原理，很多朋友都不知道 SQL 背后，居然還有編譯一說。SQL 用起來和 C#/JAVA 還是有些異樣的。寫好 SELECT * (雖然這么寫很糟糕！）以后，按下 F5 便能得到結(jié)果。而不像 C#/Java 需要經(jīng)過 CLR/JVM 這樣的“轉(zhuǎn)譯”，才能看到實(shí)實(shí)在在的程序輸入輸出窗口。

正是由于 SQL 這個(gè)隱形編譯器的存在，很多莫名的語法，看起來就很費(fèi)解。比如最讓初學(xué)者頭疼的 Left Join:

本意上，這段 SQL 要達(dá)到的目的是，找出 2020 年 1 月 1 日以來，單件商品超過 1000 元銷售額的訂單，并顯示該件商品的產(chǎn)品名。

到底為止，若能根據(jù)這個(gè)要求，完整寫出上面的 SQL，那就是合格的數(shù)據(jù)庫開發(fā)工程師了。但有些朋友，經(jīng)常會(huì)寫出這樣的 SQL：

還有這樣的 SQL：

看上去，及其相似的三段 SQL，為什么出來的結(jié)果就千差萬別呢。甚至，還會(huì)把數(shù)據(jù)庫給跑死。

這就是 SQL 編譯的底層。

要了解 SQL 編譯的底層，要從這張圖，全面入手：

而 Parsing 就是我們正確理解 SQL 執(zhí)行過程的第一步。

下面這段 SQL 是比較完整的全范本：

細(xì)心的讀者可能會(huì)留意到每個(gè) SQL 關(guān)鍵字前面都有一個(gè)用括號(hào)包起來的數(shù)字，這個(gè)數(shù)字就是 SQL 關(guān)鍵字執(zhí)行的順序。

我們通常會(huì)認(rèn)為 SELECT 是 SQL 的第一步，其實(shí) FROM 才是，緊接 From 的是 ON, JOIN. 之后才是 WHERE. 正確理解 JOIN 和 WHERE 的執(zhí)行順序，才可避免 LEFT JOIN 留下的坑。

當(dāng)然，你別以為這樣就結(jié)束了，那我也太不負(fù)責(zé)任了。接著往下讀。

當(dāng)兩表 Join 的時(shí)候，先按照 ON 的條件做了一次笛卡爾積計(jì)算。甭管按照 ON 的條件能不能匹配，匹配的上，就拼接起來；匹配不上的，暫時(shí)保留。所以 ON 這一步，兩邊的數(shù)據(jù)，都會(huì)保留在一張?zhí)摂M的大表里。

比如，上面兩張表, tblOrderHeader, tblOrderDetail. 他們的外鍵是OrderId.

這兩個(gè)表，join 起來，會(huì)有這些情況：

tblOrderHeader 有些數(shù)據(jù)，在 tblOrderDetail 里按照 OrderId 找不到對(duì)應(yīng)的訂單明晰數(shù)據(jù)。

同樣的，在 tblOrderDetail 中有些明細(xì)的訂單，卻在 tblOrderHeader 頭部中找不到訂單表頭信息，比如訂單時(shí)間，商店，會(huì)員信息等。

更常見的，是互相找不到對(duì)應(yīng)數(shù)據(jù)

用實(shí)線框，框起來的表示兩表可以互相匹配的數(shù)據(jù)。而對(duì)方表缺失的部分就用白色標(biāo)注。

兩表 Join 的初步結(jié)果就出來了，就是上面最后一張圖的情況，即保留兩表所有的數(shù)據(jù)，匹配上的，排在前頭，匹配不上的依次排在后面。但必須保留兩張表所有的數(shù)據(jù)。這要牢牢記住。

接著根據(jù)第三步 JOIN 的 Join Type(Left join, Right Join, Full Outer Join)來限制留下哪部分。

Left Join, 留下左半部分：

Right Join, 留下右半部分：

Full Outer Join , 左右都留下：

接下來，才是執(zhí)行 WHERE 命令的時(shí)候。

此時(shí)，下面這段 SQL ， 即

會(huì)比這條 SQL ， 多出來很多數(shù)據(jù)：

那是因?yàn)椋?WHERE 中，Detail.Amount > 1000 這個(gè)命令，限制了右半邊的數(shù)據(jù)必須要對(duì)應(yīng)上左半邊的OrderId, 所以 tblOrderDetail 中如果沒有 tblOrderHeader 中的OrderId, 則就被舍去。哪怕 tblOrderHeader 的 OrderDate 是符合 OrderDate 大于 2020-01-01的條件。

比如有 tblOrderHeader 是有 5 條記錄，符合 OrderDate 大于 2020-01-01的條件。

我們用紅色實(shí)星框表示符合條件的記錄

但最終，因?yàn)樵?WHERE 中添加了 Detail.Amount > 1000 的條件，相當(dāng)于把 Left join 改成了 INNER JOIN, 即增加了 Detail.OrderId IS NOT NULL 條件

下面是小編通過一些大廠的朋友要到了他們內(nèi)部的Java面試題，資料難得，而且還是近一年的真實(shí)面試題；

分別有：螞蟻金服、拼多多、阿里云、百度、唯品會(huì)、攜程、豐巢科技、樂信、軟通動(dòng)力、OPPO、銀盛支付、中國平安等初，中級(jí)，高級(jí)Java面試題集合，附帶超詳細(xì)答案，希望能幫助到大家。

還有專門針對(duì)JVM、SPringBoot、SpringCloud、數(shù)據(jù)庫、linux、緩存、消息中間件、源碼等相關(guān)面試題。

把Java電子書也分享給大家，大概有10G左右的資源