簡介
在SQL Server中，我們所常見的表與表之間的Inner Join,Outer Join都會被執行引擎根據所選的列，數據上是否有索引，所選數據的選擇性轉化為Loop Join,Merge Join,Hash Join這三種物理連接中的一種。理解這三種物理連接是理解在表連接時解決性能問題的基礎，下面我來對這三種連接的原理，適用場景進行描述。
嵌套循環連接(Nested Loop Join)
循環嵌套連接是最基本的連接,正如其名所示那樣，需要進行循環嵌套，嵌套循環是三種方式中唯一支持不等式連接的方式，這種連接方式的過程可以簡單的用下圖展示:
圖1.循環嵌套連接的第一步
圖2.循環嵌套連接的第二步
由上面兩個圖不難看出，循環嵌套連接查找內部循環表的次數等於外部循環的行數，當外部循環沒有更多的行時，循環嵌套結束。另外，還可以看出，這種連接方式需要內部循環的表有序也就是有索引），並且外部循環表的行數要小於內部循環的行數，否則查詢分析器就更傾向於Hash Join(會在本文後面講到)。
通過嵌套循環連接也可以看出，隨著數據量的增長這種方式對性能的消耗將呈現出指數級別的增長，所以數據量到一定程度時，查詢分析器往往就會采用這種方式。
下面我們通過例子來看一下循環嵌套連接,利用微軟的AdventureWorks數據庫:
圖3.一個簡單的嵌套循環連接
圖3中ProductID是有索引的，並且在循環的外部表中Product表）符合ProductID=870的行有4688條，因此，對應的SalesOrderDetail表需要查找4688次。讓我們在上面的查詢中再考慮另外一個例子,如圖4所示。
圖4.額外的列帶來的額外的書簽查找
由圖4中可以看出，由於多選擇了一個UnitPrice列，導致了連接的索引無法覆蓋所求查詢，必須通過書簽查找來進行，這也是為什麼我們要養成只 Select需要的列的好習慣，為了解決上面的問題，我們既可以用覆蓋索引，也可以減少所需的列來避免書簽查找。另外，上面符合ProductID的行僅僅只有5條，所以查詢分析器會選擇書簽查找，假如我們將符合條件的行進行增大，查詢分析器會傾向於表掃描通常來說達到表中行數的1%以上往往就會進行 table scan而不是書簽查找，但這並不絕對），如圖5所示。
圖5.查詢分析器選擇了表掃描
可以看出，查詢分析器此時選擇了表掃描來進行連接，這種方式效率要低下很多，因此好的覆蓋索引和Select *都是需要注意的地方。另外，上面情況即使涉及到表掃描，依然是比較理想的情況，更糟糕的情況是使用多個不等式作為連接時，查詢分析器即使知道每一個列的統計分布，但卻不知道幾個條件的聯合分布，從而產生錯誤的執行計劃,如圖6所示。
圖6.由於無法預估聯合分布，導致的偏差
由圖6中，我們可以看出，估計的行數和實際的行數存在巨大的偏差，從而應該使用表掃描但查詢分析器選擇了書簽查找，這種情況對性能的影響將會比表掃描更加巨大。具體大到什麼程度呢？我們可以通過強制表掃描和查詢分析器的默認計劃進行比對，如圖7所示。
圖7.強制表掃描性能反而更好
