执行SQL如下
SELECT * FROM article STRAIGHT_JOIN article_comment ON article.author_id=author_id.user_id;

在这个流程里：

• 对驱动表article做了全表扫描 ， 这个过程需要扫描1000行
  
• 从驱动表每读取一行数据都需要在article_comment表中进行全表扫描 ， 没有使用索引就需要全表扫描
  
• 因此 ， 每次都需要全表扫描被驱动表的数据
  

这还是两个非常小的表 ， 在生产环境的表动辄就是上千万 ， 如果使用这种算法估计MySQL就没有现在的盛况
当然了 ， MySQL也没有使用这种算法 ， 而是用了分块嵌套查询的算法 ， 这种思想在MySQL中很多地方都在使用
扩展
例如 ， 索引是存储在磁盘中的 ， 每次使用索引进行检索数据时会把数据从磁盘读入内存中 ， 读取的方式也是分块读取 ， 并不是一次读取完 。
假设现在操作系统需在磁盘中读取1kb的数据 ， 实际上会操作系统读取到4kb的数据 ， 在操作系统中一页的数据是4kb ， 在innodb存储引擎中默认一页的数据是16kb 。
为什么MySQL会采用分块来读取数据 ， 是因为数据的局部性原理 ， 数据和程序都有聚集成群的倾向 ， 在访问到一行数据后 ， 在之后有极大的可能性会再次访问这条数据和这条数据相邻的数据 。
四、Block Nested-Loop Join使用简单嵌套查询的方式经过上文的分析肯定是不可取的 ， 而是选择了分块的思想进行处理 。
这时 ， 执行流程是这样的

• 从驱动表article中读取数据存放在join_buffer中 ， 由于是使用的没有条件的select， 因此会把article全表数据放入内存
  
• 拿着join_buffer中的数据跟article_comment中的数据进行逐行对比
  

对应的 ， 这条SQL的explain结果如下所示

为了复现Block Nested Loop ， 咔咔装了三个版本的MySQL ， 分别为MySQL8 ， MySQL5.5 ， MySQL5.7在后两个版本中都使用的是Block Nested Loop ， 但在MySQL8中却发生了变化 。

对于hash join 下期会聊到 ， 在这个查询过程中 ， 对表article、article_comment都做了一次全表扫描 ， 因此扫描行数是2000 。
把article中的数据读取到join_buffer中是以无序数组的方式存储的 ， 对于article_comment表中的每一行 ， 都需要做1000次判断 ， 那么就需要判断的次数就是1000*1000=1000万次 。
这时你发现使用分块嵌套循环跟简单嵌套查询扫描行数是一样的 ， 但Block Nested Loop算法应用了join_buffer的这么一个内存空间 ， 因此速度上肯定会比Simple快很多 。
五、总结本期我们用三个问题来总结全文 ， 以帮助你更好的理解 。
第一个问题：能不能使用join？
通过三个演示案例 ， 现在你应该知道当关联条件的列是被驱动表的索引时 ， 是完全没有问题的 ， 也就是说当使用索引嵌套查询时 ， 是可以使用join的 。
但当使用的是分块嵌套查询 ， 这种方式扫描行数为两张表行数的乘 ， 扫描行数会非常的大 ， 会占用大量的系统资源 ， 所以这种算法的join是非常不建议使用的 。
因此当使用join时 ， 最大可能的让关联查询的列为被驱动表的索引列 ， 若不能达到这个条件则可以考虑表结构设计是否合理
第二个问题：如果使用join ， 选择大表还是小表作为驱动表？

• 为什么科学家表示人类“灭绝”的可能性极低？这些理由你赞同吗？
• 为什么科学家知道太阳的原理，却无法制造出人造太阳
• 社交|腾讯视频为IP编写「价值算法」
• 新书推荐 │ 大数据算法设计与分析
• 为什么科学家用昆虫翅膀的起源质疑进化论？达尔文到底是对是错？
• 为什么夜空是黑的？你以为的“正常”，或许隐藏着不知道的秘密
• 为什么温度高到一定程度的物体，就会发光？
• 为什么现在很少有人提及“克隆技术”了？“克隆技术”有何缺点？
• 为什么同学群里，很少有人说话，大部分人都选择沉默或者屏蔽？
• 算法|75英寸最值得入手的大屏电视，性能画质没得挑