select *
from t1 straight_join t2 on (t1.a = t2.b);

执行过程如下：

• 扫描t1，顺序读取数据行放入join_buffer，放完第88行join_buffer满了，继续第2步
• 扫描t2，把t2中的每一行取出来，跟join_buffer中的数据做对比，满足join条件的，作为结果集的一部分返回
• 清空join_buffer
• 继续扫描t1，顺序读取最后的12行数据放入join_buffer中，继续执行第2步

step4、5，表示清空join_buffer再复用。这也能看出该算法的确是分块join。

此时由于t1被分成两次放入join_buffer，导致t2会被扫描两次。虽然分成两次放入join_buffer，但判断等值条件的次数不变，依然是(88+12)*1000=10万次。

此时如何选择驱动表？
假设，驱动表数据行数N，需分K（K不是常数，N越大K就会越大，因此把K表示为λ*N，显然λ的取值范围是(0,1)）段完成，被驱动表数据行数M。
所以，该算法执行过程：

• 扫描行数
  N+λNM
• 内存判断
  N*M次

显然，内存判断次数是不受选择影响。观察扫描行数，在M和N确定时，N越小，结果越小。
所以应该让小表当驱动表。

在N+λ*N*M中，λ才是影响扫描行数的关键因素，越小越好。

N越大，分段数K越大。那么，N固定时，什么会影响K呢？（ 即λ的大小）答案是join_buffer_size：
join_buffer_size越大，一次可放入行越多，分段数越少，被驱动表全表扫描次数越少

所以若你的join很慢，就把join_buffer_size加大。

综上：

能不能使用join

若使用INL，当可以用被驱动表的索引，是没问题的。
若使用BNL，扫描行数就会过多。尤其是在大表上的join，这样可能要扫描被驱动表很多次，会占用大量的系统资源。所以这种join禁用。

所以判断要不要使用join，就是看explain结果里面，Extra字段里面有没有出现“Block Nested Loop”。

若使用join，大表or 小表做驱动表？

• INL：
  选择小表做驱动表
• BNL：
  • 在join_buffer_size足够大时，一样
  • 在join_buffer_size不够大时（常见情况），选择小表做驱动表

所以，该问题最终结论：永远使用小表做驱动表。

什么叫“小表”？

若加上 where t2.id<=50：

select *
from t1 straight_join t2 on (t1.b = t2.b)
where t2.id <= 50;

select *
from t2 straight_join t1 on (t1.b = t2.b)
where t2.id <= 50;

select t1.b, t2.*
from t1 straight_join t2 on (t1.b = t2.b)
where t2.id <= 100;

select t1.b, t2.*
from t2 straight_join t1 on (t1.b = t2.b)
where t2.id <= 100;