有很多聯接的Mysql緩慢查詢

Question

我得到的查詢在相當小的表上運行（每個行最多4000行）。查詢持續約4秒幷包含多個連接，但是，所有連接都使用索引。

下面是該查詢：

SELECT count(DISTINCT p0_.id) AS sclr0 
FROM promoter p0_ 
LEFT JOIN user u1_ ON p0_.user_id = u1_.id 
LEFT JOIN profile p2_ ON p0_.id = p2_.promoter_id 
LEFT JOIN promoter_city p4_ ON p0_.id = p4_.user_id 
LEFT JOIN city c3_ ON c3_.id = p4_.city_id 
LEFT JOIN promoter_language p6_ ON p0_.id = p6_.user_id 
LEFT JOIN language l5_ ON l5_.id = p6_.language_id 
LEFT JOIN promoter_worker_type p8_ ON p0_.id = p8_.promoter_id 
LEFT JOIN worker_type w7_ ON w7_.id = p8_.workertype_id 
LEFT JOIN practise p9_ ON p0_.id = p9_.promoter_id 
LEFT JOIN contract c11_ ON p0_.id = c11_.promoter_id 

這裏是輸出的解釋：

+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  id  | select_type |  table  |  type  | possible_keys |  key  |  key_len  |  ref  |  rows  |  Extra  | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  p0_  |  index  |     |UNIQ_BCB929A3A76ED|  5   |     |  4161  | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  u1_  |  eq_ref  |  PRIMARY  |  PRIMARY  |  4   |promoteri.p0_.user|  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  p2_  |  ref  |type,IDX_8157AA0F4|  type  |  5   | promoteri.p0_.id |  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  p4_  |  ref  |PRIMARY,IDX_183C53|  PRIMARY  |  4   | promoteri.p0_.id |  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  c3_  |  eq_ref  |  PRIMARY  |  PRIMARY  |  4   |promoteri.p4_.city|  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  p6_  |  ref  |PRIMARY,IDX_19EE2A|  PRIMARY  |  4   | promoteri.p0_.id |  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  l5_  |  eq_ref  |  PRIMARY  |  PRIMARY  |  4   |promoteri.p6_.lang|  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  p8_  |  ref  |PRIMARY,IDX_37AC17|  PRIMARY  |  4   | promoteri.p0_.id |  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  w7_  |  eq_ref  |  PRIMARY  |  PRIMARY  |  4   |promoteri.p8_.work|  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  p9_  |  ref  |IDX_352E261F4B84B2|IDX_352E261F4B84B2|  5   | promoteri.p0_.id |  1   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 
|  1   |  SIMPLE  |  c11_  |  ref  |IDX_E98F28594B84B2|IDX_E98F28594B84B2|  5   | promoteri.p0_.id |  6   | Using index | 
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+ 

我知道，該聯接是不必要在此查詢，但是我用很多類似的查詢有一些where語句應用，這些連接真的很重要。

有什麼解釋，爲什麼這個查詢需要這麼久？

Answer 1

嘗試將所有這些left joins改爲inner joins。當您使用left join時，您會強制優化器按照您提供的順序加入表格......當您使用inner join時，優化程序可以選擇更好的加入表格的起始位置。

至於對left join迫使特定讀取順序的參考 - 從MySQL Docs：

表中讀取順序被迫LEFT JOIN或STRAIGHT_JOIN幫助 聯接優化做的工作更加迅速，因爲有更少的 表排列來檢查。

...指示left join強制讀取命令與STRAIGHT_JOIN相同。