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    |
+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+

我知道，在这个查询中JOINS是不必要的，但是我使用了许多类似的查询，其中有一些where语句应用，这些连接真的很重要。

有没有解释，为什么这个查询需要这么长时间？

Answer 1

尝试将所有left joins更改为inner joins。当您使用left join时，强制优化器按照您提供的顺序连接表...当您使用inner join时，优化程序可以选择更好的起始位置来加入表。

至于left join强制执行特定阅读顺序的引用 - 来自MySQL Docs：

由LEFT JOIN或STRAIGHT_JOIN强制执行的表读取顺序有助于 join optimizer更快地完成它的工作，因为它更少要检查的表格排列。

...表示left join强制阅读顺序与STRAIGHT_JOIN相同。

Mysql慢查询有很多连接

1 个答案: