在sqlserver的联机从书中,可以看到嵌套循环联接:
如果一个联接输入很小（比如不到 10 行），而另一个联接输入很大而且已在其联接列上创建索引，则索引嵌套循环是最快的联接操作，因为它们需要最少的 I/O 和最少的比较。嵌套循环联接也称为嵌套迭代，它将一个联接输入用作外部输入表（显示为图形执行计划中的顶端输入），将另一个联接输入用作内部（底端）输入表。外部循环逐行消耗外部输入表。内部循环为每个外部行执行，在内部输入表中搜索匹配行。最简单的情况是，搜索时扫描整个表或索引；这称为单纯嵌套循环联接。如果搜索时使用索引，则称为索引嵌套循环联接。如果将索引生成为查询计划的一部分（并在查询完成后立即将索引破坏），则称为临时索引嵌套循环联接。查询优化器考虑所有这些不同形式。如果外部输入很小而内部输入很大且预先创建了索引，则嵌套循环联接尤其有效。在许多小事务中（如那些只影响较小的一组行的事务），索引嵌套循环联接远比合并联接和哈希联接优越。但在大查询中，嵌套循环联接通常不是最佳选择。合并联接:
如果两个联接输入并不小但已在二者联接列上排序（例如，如果它们是通过扫描已排序的索引获得的），则合并联接是最快的联接操作。如果两个联接输入都很大，而且这两个输入的大小差不多，则预先排序的合并联接提供的性能与哈希联接相似。然而，如果两个输入的大小相差很大，则哈希联接操作通常快得多。合并联接要求两个输入都在合并列上排序，而合并列由联接谓词的等效 (WHERE) 子句定义。查询优化器一般扫描索引（如果在适当的一组列上存在一个索引），或在合并联接的下面放一个排序运算符。在很少的情况下，虽然可能有多个等效子句，但只用其中一些可用的等效子句获得合并列。由于每个输入都已排序，Merge Join 运算符将获取每个输入中的行并将其进行比较。例如，对于内联接操作，如果行相等则返回。如果行不相等，则废弃值较小的行并从该输入中获得另一行。这一过程将重复进行，直到处理完所有的行为止。合并联接操作可以是常规操作，也可以是多对多操作。多对多合并联接使用临时表存储行。如果每个输入中有重复值，则在处理其中一个输入中的每个重复项时，另一个输入必须重绕到重复项的开始位置。如果存在驻留谓词，所有满足合并谓词的行都将对该驻留谓词取值，然后只返回那些满足该驻留谓词的行。合并联接本身的速度很快，但如果需要排序操作，选择合并联接就会非常费时。然而，如果数据量很大且能够从现有 B 树索引中获得预排序的所需数据，则合并联接通常是最快的可用联接算法。我作了一个测试,表A,aid为聚集索引,表B中bid为聚集索引,表A有30W数据，表B有70W数据SELECT a.col1,bcol2
FROM a INNER JOIN
b ON a.aid= b.bid
where a.aid=100383在查询分析器中显示，采用的是嵌套循环联接（Nested Loops/Inner Join）。这里我就有疑问了，因为“如果两个联接输入并不小但已在二者联接列上排序（例如，如果它们是通过扫描已排序的索引获得的），则合并联接是最快的联接操作。”，为什么不采用合并联接(Merge Join)呢？还有“合并联接要求两个输入都在合并列上排序，而合并列由联接谓词的等效 (WHERE) 子句定义。”，等效 (WHERE) 子句的意思是不是指的我的语句中的where a.aid=100383？如果我建立视图View的sql语句为：
SELECT a.aid,a.col1,bcol2
FROM a INNER JOIN
b ON a.aid= b.bid那么select * from view where aid = 100383,那这里算不算等效 (WHERE) 子句呢？有请各位对嵌套循环联接、合并联接以及哈希联接熟悉或者感兴趣的进行讨论！！最好能举一些实例哦～～
如果一个联接输入很小（比如不到 10 行），而另一个联接输入很大而且已在其联接列上创建索引，则索引嵌套循环是最快的联接操作，因为它们需要最少的 I/O 和最少的比较。嵌套循环联接也称为嵌套迭代，它将一个联接输入用作外部输入表（显示为图形执行计划中的顶端输入），将另一个联接输入用作内部（底端）输入表。外部循环逐行消耗外部输入表。内部循环为每个外部行执行，在内部输入表中搜索匹配行。最简单的情况是，搜索时扫描整个表或索引；这称为单纯嵌套循环联接。如果搜索时使用索引，则称为索引嵌套循环联接。如果将索引生成为查询计划的一部分（并在查询完成后立即将索引破坏），则称为临时索引嵌套循环联接。查询优化器考虑所有这些不同形式。如果外部输入很小而内部输入很大且预先创建了索引，则嵌套循环联接尤其有效。在许多小事务中（如那些只影响较小的一组行的事务），索引嵌套循环联接远比合并联接和哈希联接优越。但在大查询中，嵌套循环联接通常不是最佳选择。合并联接:
如果两个联接输入并不小但已在二者联接列上排序（例如，如果它们是通过扫描已排序的索引获得的），则合并联接是最快的联接操作。如果两个联接输入都很大，而且这两个输入的大小差不多，则预先排序的合并联接提供的性能与哈希联接相似。然而，如果两个输入的大小相差很大，则哈希联接操作通常快得多。合并联接要求两个输入都在合并列上排序，而合并列由联接谓词的等效 (WHERE) 子句定义。查询优化器一般扫描索引（如果在适当的一组列上存在一个索引），或在合并联接的下面放一个排序运算符。在很少的情况下，虽然可能有多个等效子句，但只用其中一些可用的等效子句获得合并列。由于每个输入都已排序，Merge Join 运算符将获取每个输入中的行并将其进行比较。例如，对于内联接操作，如果行相等则返回。如果行不相等，则废弃值较小的行并从该输入中获得另一行。这一过程将重复进行，直到处理完所有的行为止。合并联接操作可以是常规操作，也可以是多对多操作。多对多合并联接使用临时表存储行。如果每个输入中有重复值，则在处理其中一个输入中的每个重复项时，另一个输入必须重绕到重复项的开始位置。如果存在驻留谓词，所有满足合并谓词的行都将对该驻留谓词取值，然后只返回那些满足该驻留谓词的行。合并联接本身的速度很快，但如果需要排序操作，选择合并联接就会非常费时。然而，如果数据量很大且能够从现有 B 树索引中获得预排序的所需数据，则合并联接通常是最快的可用联接算法。我作了一个测试,表A,aid为聚集索引,表B中bid为聚集索引,表A有30W数据，表B有70W数据SELECT a.col1,bcol2
FROM a INNER JOIN
b ON a.aid= b.bid
where a.aid=100383在查询分析器中显示，采用的是嵌套循环联接（Nested Loops/Inner Join）。这里我就有疑问了，因为“如果两个联接输入并不小但已在二者联接列上排序（例如，如果它们是通过扫描已排序的索引获得的），则合并联接是最快的联接操作。”，为什么不采用合并联接(Merge Join)呢？还有“合并联接要求两个输入都在合并列上排序，而合并列由联接谓词的等效 (WHERE) 子句定义。”，等效 (WHERE) 子句的意思是不是指的我的语句中的where a.aid=100383？如果我建立视图View的sql语句为：
SELECT a.aid,a.col1,bcol2
FROM a INNER JOIN
b ON a.aid= b.bid那么select * from view where aid = 100383,那这里算不算等效 (WHERE) 子句呢？有请各位对嵌套循环联接、合并联接以及哈希联接熟悉或者感兴趣的进行讨论！！最好能举一些实例哦～～
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货