聯表查詢時始終以小結果集驅動大結果集

寫在前面的話

不要求每一個人必定理解 聯表查詢(join/left join/inner join等)時的mysql運算過程；

不要求每一個人必定知道線上（如今或將來）哪張表數據量大，哪張表數據量小；

但要常常使用explain查看執行計劃，這是一種美德！

聯表查詢的基礎知識

下面兩個查詢，它們只差了一個order by，效果卻迥然不一樣。

第一個查詢：

EXPLAIN extended SELECT ads.id FROM ads, city WHERE city.city_id = 8005

   AND ads.status = 'online'

   AND city.ads_id=ads.id ORDER BY ads.id desc

執行計劃爲：

id  select_type  table   type    possible_keys   key key_len ref rows filtered Extra ------ ----------- ------ ------ -------------- ------- ------- -------------------- ------ -------- -------------------------------
 1  SIMPLE       city    ref     ads_id,city_id  city_id  4        const                   2838    100.00  Using temporary; Using filesort 1  SIMPLE       ads     eq_ref  PRIMARY         PRIMARY  4        city.ads_id       1    100.00  Using where

第二個查詢：

EXPLAIN extended SELECT ads.id FROM ads,city WHERE city.city_id =8005

   AND ads.status = 'online'

   AND city.ads_id=ads.id ORDER BY city.ads_id desc

執行計劃裏沒有了using temporary：

id  select_type  table   type    possible_keys   key key_len ref rows filtered Extra ------ ----------- ------ ------ -------------- ------- ------- -------------------- ------ -------- ---------------------------
  1  SIMPLE       city    ref     ads_id,city_id  city_id  4        const                   2838    100.00  Using where; Using filesort 1  SIMPLE       ads    eq_ref  PRIMARY         PRIMARY  4        city.ads_id       1    100.00  Using where

爲何第一個查詢using temporary，第二個查詢不用臨時表呢？

DBA告訴咱們， MySQL 表關聯的算法是 Nest Loop Join， 是經過驅動表的結果集做爲循環基礎數據，而後一條一條地經過該結果集中的數據做爲過濾條件到下一個表中查詢數據，而後合併結果。

EXPLAIN 結果中，第一行出現的表就是驅動表（Important!）

以上兩個查詢語句，驅動表都是 city，如上面的執行計劃所示！

對驅動表能夠直接排序，對非驅動表（的字段排序）須要對循環查詢的合併結果（臨時表）進行排序（Important!）

所以，order by ads.id desc 時，就要先 using temporary 了！

驅動表的定義

當進行多表鏈接查詢時， 驅動表的定義爲：
1）指定了聯接條件時，知足查詢條件的記錄行數少的表爲驅動表；
2）未指定聯接條件時，行數少的表爲驅動表（Important!）。

忠告：若是你搞不清楚該讓誰作驅動表、誰 join 誰，請讓 MySQL 運行時自行判斷

既然未指定聯接條件時，行數少的表爲驅動表了，並且你也對本身寫出的複雜的 Nested Loop Join 不太有把握（以下面的實例所示），那 就別指定誰 left/right join 誰了， 請交給 MySQL優化器 運行時決定吧。

小結果集驅動大結果集

咱們 優化的目標是儘量減小JOIN中Nested Loop的循環次數，以此保證： 永遠用小結果集驅動大結果集 （Important!）！

實例講解

先了解一下 mb 表有 千萬級記錄，mbei 表要少得多。慢查實例以下：

explain SELECT mb.id, …… FROMmb LEFT JOIN mbei ON mb.id=mbei.mb_id INNER JOIN u ON mb.uid=u.uid WHERE 1=1  
ORDER BY mbei.apply_time DESC limit 0,10

夠複雜吧。Nested Loop Join 就是這樣，以驅動表的結果集做爲循環的基礎數據，而後將結果集中的數據做爲過濾條件一條條地到下一個表中查詢數據，最後合併結果；此時還有第三個表，則將前兩個表的 Join 結果集做爲循環基礎數據， 再一次經過循環查詢條件到第三個表中查詢數據，如此反覆。

這條語句的執行計劃以下：

id  select_type  table   type    possible_keys   key key_len ref rows Extra ------ ----------- ------ ------ -------------- -------------- ------- ------------------- ------- --------------------------------------------
  1  SIMPLE       mb      index   userid          userid          4        (NULL)               6060455  Using index; Using temporary; Using filesort 1  SIMPLE       mbei    eq_ref  mb_id  mb_id  4        mb.id             1                                              
  1  SIMPLE       u       eq_ref  PRIMARY         PRIMARY         4        mb.uid        1  Using index

因爲動用了「LEFT JOIN」，因此攻城獅已經指定了驅動表，雖然這張驅動表的結果集記錄數達到百萬級！

如何優化？

優化第一步：LEFT JOIN改成JOIN

幹嗎要 left join 啊？直接 join！

explain SELECT mb.id…… FROM mb JOIN mbei ON mb.id=mbei.mb_id INNER JOIN u ON mb.uid=u.uid WHERE 1=1  
ORDER BY mbei.apply_time DESC limit 0,10

立竿見影，驅動表馬上變爲小表 mbei 了， Using temporary 消失了，影響行數少多了：

id  select_type  table   type    possible_keys   key key_len ref rows Extra ------ ----------- ------ ------ -------------- ------- ------- ---------------------------- ------ --------------
   1  SIMPLE       mbei    ALL     mb_id  (NULL)   (NULL)   (NULL)                         13383 Using filesort 1  SIMPLE       mb      eq_ref  PRIMARY,userid  PRIMARY  4        mbei.mb_id       1                
   1  SIMPLE       u       eq_ref  PRIMARY         PRIMARY  4        mb.uid                1  Using index

優化第一步之分支1：儘可能不要根據非驅動表的字段排序

left join不變。幹嗎要根據非驅動表的字段排序呢？咱們前面說過「對驅動表能夠直接排序，對非驅動表（的字段排序）須要對循環查詢的合併結果（臨時表）進行排序！」的。

explain SELECT mb.id…… FROM mb LEFT JOIN mbei ON mb.id=mbei.mb_id INNER JOINu ON mb.uid=u.uid WHERE 1=1  
ORDER BY mb.id DESC limit 0,10

也知足業務場景，作到了rows最小：

id  select_type  table   type    possible_keys   key key_len ref rows Extra ------ ----------- ------ ------ -------------- -------------- ------- ------------------- ------ -----------
  1  SIMPLE       mb      index   userid          PRIMARY         4        (NULL)                   10             
  1  SIMPLE       mbei    eq_ref  mb_id  mb_id  4        mb.id            1  Using index
  1  SIMPLE       u       eq_ref  PRIMARY         PRIMARY         4        mb.uid       1  Using index

優化第二步：去除全部JOIN，讓MySQL自行決定！

寫這麼多密密麻麻的 left join/inner join 很開心嗎？

explain SELECT mb.id…… FROM mb,mbei,u  WHERE mb.id=mbei.mb_id and mb.uid=u.user_id
order by mbei.apply_time desc limit 0,10

立竿見影，驅動表同樣是小表 mbei：

id  select_type  table   type    possible_keys   key key_len ref rows Extra ------ ----------- ------ ------ -------------- ------- ------- ---------------------------- ------ --------------
  1  SIMPLE       mbei    ALL     mb_id  (NULL)   (NULL)   (NULL)                         13388 Using filesort 1  SIMPLE       mb      eq_ref  PRIMARY,userid  PRIMARY  4        mbei.mb_id       1                
  1  SIMPLE       u       eq_ref  PRIMARY         PRIMARY  4        mb.uid                1  Using index

總結

不要過於相信你的運氣！

不要相信你的開發環境裏SQL的執行速度！

請拿起 explain 武器，

若是你看到如下現象，請優化：

• 出現了Using temporary；
• rows過多，或者幾乎是全表的記錄數；
• key 是 (NULL)；
• possible_keys 出現過多（待選）索引。