----如有明显讹误，请广大网友指正------
DBA都知道，表和表的连接有三种方式，即：嵌套循环、合并连接、还有哈希连接。
三种连接方式没有谁更好的这一说，优化器会根据不同场景下参与连接的数据自身的特点，选择合适的连接算法。
但如优化器因统计信息不准或者自身缺陷，出现选择错误的情况【出现选择错误会影响执行效率，并不是不能运行哈】，则需要DBA干预和指定连接方式。
相信大家都大量阅读锅关于这三个连接的解释和说明，但是未必能够十分清晰地记在脑海里，这个我想主要还是缺少一些通俗的解释和对应。
这里不讨论关于实现的技术细节，只想通俗的做一个解释，同时顺便讨论一下他们的适用场景。【内容主要来自于梁敬彬老师的《收获不止Oracle》】
以下比喻和实际运行情况的原理大致相似，但并非高度一致，大家不必太较真，把大致的原理讲清楚即可。
---------------------------------------------------------------------------------------------------------------------------------
假设现在要进行一场舞会，舞会的规则是男女生按照身高结伴跳舞。在舞会开始前，男生在A房间，女生在B房间，舞池在中央。
请看第1种方式，在A房间走出第1个男生，进入到B房间找到和自己高度匹配的女生，然后结伴。
在A房间走出第2个男生，进入到B房间找到和自己高度匹配的女生，然后结伴。
....
在A房间走出第N个男生, 进入到B房间找到和自己高度匹配的女生，然后结伴。
其实这类似嵌套循环。A表返回N行，则B表需要扫描N次。【Nested Loop】
------------------------------------------------------------------------------------------------
请看第2种方式，在A房间里按身高对男生进行排序，在B房间按身高对女生进行排序。
然后A房间的第1个男生与B房间第1个女生，结伴。
然后A房间的第2个男生与B房间第2个女生，结伴。
....
然后A房间的第N个男生与B房间第N个女生，结伴。
其实这个是合并连接，主要的开销在A表，B表自身的排序上。【Merge Join】
这上面两种方式哪种更好呢，这就要看男女生自身分布的具体情况了，这就是我前面讲的优化器会根据参与连接的数据分布的特点选择合适的算法。
如果说A房间里只有1个男生【A表只有1行】或者仅有1个男生【A表有很多行，但是where只选择了一行】, 这种情况自然是第1种方式更快。当然实际情况是A表仅有少数行的情况就适用这种连接，同时如果B表连接列上有索引就更好，直接通过索引找到要匹配的数据。
所以：嵌套循环适用场景是： 外表返回记录小，且内表循环条件列有序。
如果说A房间的男生和B房间的女生都很多，并且所有的男生均要参加舞会，但是男生进入到A房间的时候就是按照身高排序进去的，女生进入B房间也是按照身高有序进去的，那么就可以直接按照A房间第1个男生和B房间第1个女生结伴出来跳舞就可以了，也就是说如果A表连接列和B表的连接列本身就排过序了。
所以：合并连接适用场景是： 两张表的数据都挺大的，同时也都是有序的。
--------------------------------------------------------------------------------------------------------------------------------------------------------------
如果遇到要参与舞会的男生N多，女生的数量也M多，并且男生和女生也是杂乱无章的分布在A房间和B房间。那么这种情况怎么处理比较合适呢？
这个时候舞会组织者会采取一种高超的方式：
花点时间把1米55以下女生的进入到B1区，1米55~1米60的进入B2区，1米60到1米65的进去B3区,1米65以上的进入到B4区。然后挨个对每1个男生出来，我们也要衡量男生身高，然后让他到对应B房间的区域去寻找自己合适的女生。
所以：哈希连接适用场景是： 两张数据量大，且都是无序的。由于要进行哈希运算，CPU的消费会高一些。
