MYSQL(06)-JOIN优化

JOIN查询原理
如果有两张数据结构一样的表(id-主键) ,(a有索引) ,(b无索引)。其中表t1(100条数据) 和t2(1000条数据),他们做join查询的时候,内部执行的原理是什么呢?

INLJ-(Index Nested-Loop Join)

// 使用straight_join表示,固定指定 t1是驱动表,t2是被驱动表,防止优化器优化
select * from t1 straight_join t2 on (t1.a=t2.a);
  • 1.从表t1中读取一行数据R
  • 2.从R中取出字段a去t2中查找
  • 3.取出t2中满足要求的数据,和R合并组成结果集中的一条数据
  • 4.重复1到3的步骤,流程图如下
MYSQL(06)-JOIN优化_第1张图片

上述因为被驱动表中使用了索引故,该join方法我们称之为(NLJ),这个流程中。对于表t1扫描的全表,故扫描了100行。对于表t2因为走了索引的树搜索,故t2表也是扫描了100行,索引这个join操作执行了200次扫描。这时如果反过来t2作为驱动表,则需要扫描2000次数据,故使用NLJ的时候,尽量使用小表作为驱动表

试想以下,如果上述t2没有使用索引,那么t1查询出的R对应查询t2的数据时,每次都要全表遍历1000次,那么查询的次数就要达到,100*1000=10W次查询了,这种查询方法叫做Simple Nested-Loop Join(SNLJ),因为效率实在太低,所以mysql根本没有使用这种方法。而是使用的Block Nested-Loop Join

BNLJ (Block Nested-Loop Join)

对于t1的数据并没有一条条读取,而是将t1的数据一次性加载到join_buffer的缓存中,然后扫描表t2与join_buffer中的每条数据做比对,最终一共扫描数据的次数是100+1000=1100次,大大增加了效率


MYSQL(06)-JOIN优化_第2张图片

不过join_buffer 的内存是有限的,如果join_buffer中放不下t1的表的所有数据,那么他会将数据分几次来放,所以驱动表t1的数据越小,分的次数也就越小,查询的效率就会越高
从上诉的BLJ还是NLJ算法得知,驱动表尽可能的要使用小表,但是什么数据条数少的表就是小表么?

案例一:

对于上面的数据,我们执行以下语句

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

这时,t2增加了where条件,那么t2作为驱动表,加载到join_buffer中的大小则只有50条,这时t2才是小表

案例二:

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

这时,t1 和t2都增加了where条件,条数都是100条,但是t1只查询了id列,所以这时t1是小表

你可能感兴趣的:(MYSQL(06)-JOIN优化)