導(dǎo)讀:1建站知識(shí)理解這三種物理連接是理解在表連接時(shí)解決性能問題的基礎(chǔ)，下面我來對(duì)這三種連接的原理，適用場(chǎng)景進(jìn)行描述網(wǎng)站優(yōu)化seo培訓(xùn)如何seo優(yōu)化推廣網(wǎng)站。

在SQL Server中，我們所常見的表與表之間的Inner Join,Outer Join都會(huì)被執(zhí)行引擎根據(jù)所選的列，數(shù)據(jù)上是否有索引，所選數(shù)據(jù)的選擇性轉(zhuǎn)化為L(zhǎng)oop Join,Merge Join,Hash Join這三種物理連接中的一種。理解這三種物理連接是理解在表連接時(shí)解決性能問題的基礎(chǔ)，下面我來對(duì)這三種連接的原理，適用場(chǎng)景進(jìn)行描述。 嵌套循環(huán)連接(Nested Loop Join) 循環(huán)嵌套連接是最基本的連接,正如其名所示那樣，需要進(jìn)行循環(huán)嵌套，嵌套循環(huán)是三種方式中唯一支持不等式連接的方式，這種連接方式的過程可以簡(jiǎn)單的用下圖展示:

圖2.循環(huán)嵌套連網(wǎng)站seo優(yōu)化診斷工具接的第二步

由上面兩個(gè)圖不難看出，循環(huán)嵌套連接查找內(nèi)部循環(huán)表的次數(shù)等于外部循環(huán)的行數(shù)，當(dāng)外部循環(huán)沒有更多的行時(shí)，循環(huán)嵌套結(jié)束。另外，還可以看出，這種連接方式需要內(nèi)部循環(huán)的表有序（也就是有索引），并且外部循環(huán)表的行數(shù)要小于內(nèi)部循環(huán)的行數(shù)，否則查詢分析器就更傾向于Hash Join(會(huì)在本文后面講到)。

通過嵌套循環(huán)連接也可以看出，隨著數(shù)據(jù)量的增長(zhǎng)這種方式對(duì)性能的消耗將呈現(xiàn)出指數(shù)級(jí)別的增長(zhǎng)，所以數(shù)據(jù)量到一定程度時(shí)，查詢分析器往往就會(huì)采用這種方式。

下面我們通過例子來看一下循環(huán)嵌套連接,利用微軟的AdventureWorks數(shù)據(jù)庫(kù):

圖3中ProductID是有索引的，并且在循環(huán)的外部表中（Product表）符合ProductID=870的行有4688條，因此，對(duì)應(yīng)的SalesOrderDetail表需要查找4688次。讓我們?cè)谏厦娴牟樵冎性倏紤]另外一個(gè)例子,如圖4所示。

由圖4中可以看出，由于多選擇了一個(gè)UnitPrice列，導(dǎo)致了連接的索引無法覆蓋所求查詢，必須通過書簽查找來進(jìn)行，網(wǎng)站優(yōu)化seo培訓(xùn)這也是為什么我們要養(yǎng)成只Select需要的列的好習(xí)慣，為了解決上面的問題，我們既可以用覆蓋索引，也可以減少所需的列來避免書簽查找。另外，上面符合ProductID的行僅僅只有5條，所以查詢分析器會(huì)選擇書簽查找，假如我們將符合條件的行進(jìn)行增大，查詢分析器會(huì)傾向于表掃描（通常來說達(dá)到表中行數(shù)的1%以上往往就會(huì)進(jìn)行table scan而不是書簽查找，但這并不絕對(duì)），如圖5所示。

可以看出，查詢分析器此時(shí)選擇了表掃描來進(jìn)行連接，這種方式效率要低下很多，因此好的覆蓋索引和Select *都是需要注意的地方。另外，上面情況即使涉及到表掃描，依然是比較理想的情況，更糟糕的情況是使用多個(gè)不等式作為連接時(shí)，查詢分析器即使知道每一個(gè)列的統(tǒng)計(jì)分布，但卻不知道幾個(gè)條件的聯(lián)合分布，從而產(chǎn)生錯(cuò)誤的執(zhí)行計(jì)劃,如圖6所示。

關(guān)鍵詞標(biāo)簽: 三種 淺談 SQL