以下的文章主要描述的是SQL Server 2005合并聯(lián)接的正確算法，在實(shí)際操作中如果遇到兩個(gè)聯(lián)接輸入而且不小但已在二者，其聯(lián)接列上排序(例如，如果它們是通過(guò)掃描已排序的索引獲得的)，則合并聯(lián)接是最快的聯(lián)接操作。

如果兩個(gè)聯(lián)接輸入都很大，而且這兩個(gè)輸入的大小差不多，則預(yù)先排序的SQL Server 2005合并聯(lián)接提供的性能與哈希

如果兩個(gè)聯(lián)接輸入并不小但已在二者聯(lián)接列上排序(例如，如果它們是通過(guò)掃描已排序的索引獲得的)，則合并聯(lián)接是最快的聯(lián)接操作。如果兩個(gè)聯(lián)接輸入都很大，而且這兩個(gè)輸入的大小差不多，則預(yù)先排序的SQL Server 2005合并聯(lián)接提供的性能與哈希聯(lián)接相近。

從上次我們分析來(lái)看，嵌套循環(huán)適合輸入和輸出都小的情況，那如果輸入和輸入都比較大情況下，使用合并算法什么情況下最優(yōu)。

最佳使用:

合并聯(lián)接本身的速度很快，但如果需要排序操作，選擇SQL Server 2005合并聯(lián)接就會(huì)非常費(fèi)時(shí)。然而，如果數(shù)據(jù)量很大且能夠從現(xiàn)有 B 樹(shù)索引中獲得預(yù)排序的所需數(shù)據(jù)，則合并聯(lián)接通常是最快的可用聯(lián)接算法。

我們來(lái)測(cè)試一下，合并連接的最優(yōu)情況：

測(cè)試環(huán)境：表：workflowinfo1 約45萬(wàn)條 表workflowbase1 約4.5萬(wàn)條

條件：workflowbase1中列id，creater都建立索引，workflowinfo1中workflowid建立了索引。

如果兩個(gè)聯(lián)接輸入并不小但已在二者聯(lián)接列上排序(例如，如果它們是通過(guò)掃描已排序的索引獲得的)，則SQL Server 2005合并聯(lián)接是最快的聯(lián)接操作。如果兩個(gè)聯(lián)接輸入都很大，而且這兩個(gè)輸入的大小差不多，則預(yù)先排序的合并聯(lián)接提供的性能與哈希聯(lián)接相近。~：(creater=4028814110830a1e01108fe379e60061’的workflowbase1表有1023條數(shù)據(jù))

測(cè)試語(yǔ)句：

合并算法

select a.* from workflowbase1 a inner merge join dbo.workflowinfo1 b   
on a.id=b.workflowid and a.creater='4028814110830a1e01108fe379e60061' 

hash算法

select a.* from workflowbase1 a inner hash join dbo.workflowinfo1 b   
on a.id=b.workflowid and a.creater='4028814110830a1e01108fe379e60061' 

注意:這兩條SQL和上一個(gè)嵌套循環(huán)的例子有區(qū)別，一個(gè) select * 和一個(gè)是 select a.*

重啟數(shù)據(jù)庫(kù)服務(wù)，查看成本：

執(zhí)行結(jié)果:

(10468 行受影響)

表'workflowinfo1'。掃描計(jì)數(shù)1，邏輯讀取3527 次，物理讀取1 次，預(yù)讀3528 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

表'workflowbase1'。掃描計(jì)數(shù)1，邏輯讀取1571 次，物理讀取0 次，預(yù)讀1624 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

(10468 行受影響)

表'workflowbase1'。掃描計(jì)數(shù)3，邏輯讀取1571 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

表'workflowinfo1'。掃描計(jì)數(shù)3，邏輯讀取3886 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

表'Worktable'。掃描計(jì)數(shù)0，邏輯讀取0 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

這,時(shí)，Merge算法比Hash算法少了357次IO。這時(shí)發(fā)現(xiàn)，成本對(duì)比，合并連接要優(yōu)于hash連接,排序使用了B-tree索引的排序，大表workflowinfo1就沒(méi)有排序操作。

這里驗(yàn)證了上面的一句話:

如果數(shù)據(jù)量很大且能夠從現(xiàn)有 B 樹(shù)索引中獲得預(yù)排序的所需數(shù)據(jù)，則SQL Server 2005合并聯(lián)接通常是最快的可用聯(lián)接算法

如果我們換一下，將select a.*換成select *， 看看成本

這里hash連接是最優(yōu)的算法

執(zhí)行結(jié)果：

(10468 行受影響)

表'workflowbase1'。掃描計(jì)數(shù)3，邏輯讀取1571 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

表'workflowinfo1'。掃描計(jì)數(shù)3，邏輯讀取9604 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

(10468 行受影響)y

表'Worktable'。掃描計(jì)數(shù)0，邏輯讀取0 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

表'workflowinfo1'。掃描計(jì)數(shù)1，邏輯讀取9604 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

表'workflowbase1'。掃描計(jì)數(shù)1，邏輯讀取1571 次，物理讀取0 次，預(yù)讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預(yù)讀0 次。

這里的hash和merge的io次數(shù)一樣，但merge連接里多了一個(gè)排序操作，占到整個(gè)成本的60&,的確驗(yàn)證了上面的一句話：

合并聯(lián)接本身的速度很快，但如果需要排序操作，選擇SQL Server 2005合并聯(lián)接就會(huì)非常費(fèi)時(shí)。

兩個(gè)聯(lián)接輸入并不小但已在二者聯(lián)接列上排序，則SQL Server 2005合并聯(lián)接是最快的聯(lián)接操作。如果沒(méi)有排序hash連接是最優(yōu)的操作。

注意：這里的排序指兩個(gè)輸入集合必須按相等列進(jìn)行分別排序。而不是按其他列排序。

【編輯推薦】

1. SQL Server2000連接錯(cuò)誤的緣由有哪些？
2. SQL Server實(shí)例中對(duì)另個(gè)實(shí)例的調(diào)用
3. SQL Server 2000的安全策略的正確打造
4. SQL Server 數(shù)據(jù)導(dǎo)入的實(shí)際行為規(guī)范描述
5. MS SQL Server問(wèn)題與其正確解答方案