mysql百万数据关联查询优化

前段时间写过一篇MySQL Join的底层实现原理，里面稍微有提到怎么经过索引优化，即Index Nested-Loop Join，今天在获取数据时，正好作到了优化一下。

表1（T1）：

T1 count.png

表2（T2）：

T2 count.png

能够看到T1有33万数据，T2有50万数据，sql语句是：

select tbj.OWNER_TYPE, tpo.OWNER_NAME, tpo.PRINCIPAL, tbj.LICENSE_NUMBER, 
tpo.ADDRESS, tpo.CANCODE, tbj.SCOPE_BUSINESS from tf_pt_owner tpo
left JOIN tf_bs_jurctc tbj
on tpo.OWNER_ID = tbj.OWNER_ID;
复制代码

由于要查出全部数据，因此没有where条件，这样，在没有任何优化的状况下，查询所需时间为：

为何呢？由于没有索引之类的，left join会使用Block Nested-Loop Join的方式去关联表查询，T1有30万数据，T2有50万数据，那么sql须要扫描的数据就至关于300000*500000，可想而知这是很是恐怖的。

未加索引所用时间

实在等不下去了，用了1572s的时间只查出来17236条数据，总数据有540000条，所有查出来不知道等到何时去了。

通常咱们会将数据量小的表看成驱动表（T1），这也就是通常状况下Join的效率高于Left Join的缘由，由于mysql默认会将小表做为驱动表，而在匹配表（T2）中跟驱动表关联的字段咱们就能够在此建立一个索引，那么效果如何呢？

加索引查询时间

能够看到效率提升了不是一点两点，虽然如今还须要10s的查询时间。

最后，如何优化left join
一、条件中尽可能可以过滤一些行将驱动表变得小一点，用小表去驱动大表

二、右表的条件列必定要加上索引（主键、惟一索引、前缀索引等），最好可以使type达到range及以上（ref,eq_ref,const,system）

三、无视以上两点，通常不要用left join~~！