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~~！