此查询运行超过 12 秒，即使所有表都相对较小 - 大约 2000 行。

SELECT attr_73206_ AS attr_73270_ 
 FROM object_73130_ f1 
 LEFT OUTER JOIN (
   SELECT id_field, attr_73206_ FROM (
     SELECT m.id_field, t0.attr_73102_ AS attr_73206_ FROM object_73200_ o
     INNER JOIN master_slave m ON (m.id_object = 73130 OR m.id_object = 73290) AND (m.id_master = 73200 OR m.id_master = 73354) AND m.id_slave_field = o.id 
     INNER JOIN object_73101_ t0 ON t0.id = o.attr_73206_ 
     ORDER BY o.id_order 
   ) AS o GROUP BY o.id_field 
 ) AS o ON f1.id = o.id_field

两个表都有字段 id 作为主键。此外，id_field、id_order、attr_73206_和master_slave中的所有字段都被索引。至于这个查询的逻辑，总体上是master-detail类型的。表 object_73130_ 是主表，表 object_73200_ 是明细表。它们由 master_slave 表链接。 object_73101_ 是一个临时表，用于通过其 id 获取字段 attr_73206_ 的实际值。对于主表中的每一行，查询从其详细表的第一行返回一个字段。首先，查询有另一种外观，但在 stackoverflow 上我被建议使用这个更优化的结构(而不​​是以前使用的子查询，顺便说一下，查询开始运行得更快)。我观察到第一个 JOIN block 中的子查询运行得非常快，但返回的行数与主主表中的行数相当。无论如何，我不知道如何优化它。我只是想知道为什么一个简单的快速连接会造成这么多麻烦。哦，主要的观察结果是，如果我从查询中删除一个临时 object_73101_ 以仅返回一个 id，而不是一个实际值，那么查询运行起来就像闪光灯一样快。所以，所有的注意力都应该集中在这部分查询上

INNER JOIN object_73101_ t0 ON t0.id = o.attr_73206_

为什么它会如此可怕地减慢整个查询？

编辑

这样运行速度超快

SELECT t0.attr_73102_ AS attr_73270_ 
FROM object_73130_ f1 
LEFT OUTER JOIN (
SELECT id_field, attr_73206_ FROM (
    SELECT m.id_field, attr_73206_ FROM object_73200_ o
    INNER JOIN master_slave m ON (m.id_object = 73130 OR m.id_object = 73290)  AND (m.id_master = 73200 OR m.id_master = 73354) AND m.id_slave_field = o.id 
    ORDER BY o.id_order 
) AS o GROUP BY o.id_field 
) AS o ON f1.id = o.id_field
LEFT JOIN object_73101_ t0 ON t0.id = o.attr_73206_ 

所以，您可以看到，我只是将临时连接放在子查询之外。但是，问题是，子查询是自动创建的，我可以访问创建它的算法部分，我可以修改这个算法，但我无法访问构建整个查询的算法部分，所以我唯一能做的就是以某种方式修复子查询。无论如何，我仍然不明白为什么子查询中的 INNER JOIN 会使整个查询减慢数百倍。

编辑

一个新版本的查询，每个表都有不同的别名。这对性能没有影响:

SELECT attr_73206_ AS attr_73270_ 
FROM object_73130_ f1 
LEFT OUTER JOIN (
SELECT id_field, attr_73206_ FROM (
    SELECT m.id_field, t0.attr_73102_ AS attr_73206_ FROM object_73200_ a
    INNER JOIN master_slave m ON (m.id_object = 73130 OR m.id_object = 73290)  AND (m.id_master = 73200 OR m.id_master = 73354) AND m.id_slave_field = a.id 
    INNER JOIN object_73101_ t0 ON t0.id = a.attr_73206_ 
    ORDER BY a.id_order 
) AS b GROUP BY b.id_field 
) AS c ON f1.id = c.id_field

编辑

这是 EXPLAIN 命令的结果:

| id | select_type  |  TABLE  |  TYPE  | possible_keys         |     KEY     | key_len  |   ROWS  |  Extra                          |
| 1  |  PRIMARY     |   f1    |  INDEX |  NULL                 |    PRIMARY  |   4      |  1570   | USING INDEX
| 1  |  PRIMARY     | derived2|  ALL   |  NULL                 |    NULL     |  NULL    |  1564   |
| 2  |  DERIVED     | derived3|  ALL   |  NULL                 |    NULL     |  NULL    |  1575   | USING TEMPORARY; USING filesort
| 3  |  DERIVED     | m       | RANGE  | id_object,id_master,..|   id_object |   4      |  1356   | USING WHERE; USING TEMPORARY; USING filesort 
| 3  |  DERIVED     | a       | eq_ref | PRIMARY,attr_73206_   |   PRIMARY   |   4      |    1    |
| 3  |  DERIVED     | t0      | eq_ref | PRIMARY               |   PRIMARY   |   4      |    1    |

这有什么问题吗？

编辑

这是“超快”查询的 EXPLAIN 命令的结果

| id | select_type  |  TABLE  | TYPE  | possible_keys        |     KEY     | key_len  |   ROWS  |  Extra                          
| 1  |  PRIMARY     |   f1    | INDEX | NULL                 |    PRIMARY  |   4      |  1570   | USING INDEX
| 1  |  PRIMARY     | derived2| ALL   | NULL                 |    NULL     |  NULL    |  1570   |
| 1  |  PRIMARY     | t0      | eq_ref| PRIMARY              |    PRIMARY  |   4      |  1      | 
| 2  |  DERIVED     | derived3| ALL    | NULL                |   NULL      |   NULL   |  1581   | USING TEMPORARY; USING filesort 
| 3  |  DERIVED     | m       | RANGE  | id_object,id_master,|   id_bject  |   4      |  1356   | USING WHERE; USING TEMPORARY; USING filesort
| 3  |  DERIVED     | a       | eq_ref | PRIMARY             |   PRIMARY   |   4      |    1    |

关闭

我将使用我自己的“超快”查询，如上文所述。我认为不可能再对其进行优化。

最佳答案

在不知道数据/查询的确切性质的情况下，我看到了几件事:

1. 众所周知，MySQL 不擅长处理子选择，因为它需要创建派生表。事实上，某些版本的 MySQL 在使用子查询时也会忽略索引。通常，最好使用 JOIN 而不是子选择，但如果您需要使用子选择，最好使该子选择尽可能精简。

2. 除非您有非常具体的原因将 ORDER BY 放在子选择中，否则最好将其移至“主要”查询部分，因为结果集可能更小(允许更快的排序)。

综上所述，我尝试使用 JOIN 逻辑重写您的查询，但我想知道最终值 (attr_73102_) 来自哪个表？是sub-select的结果，还是来自表object_73130_？如果它来自子选择，那么我不明白你为什么要为原来的 LEFT JOIN 而烦恼，因为你只会从子选择中返回值列表，而对于任何不匹配的行则返回 NULL来自 object_73130_。

无论如何，不​​知道这个答案，我认为下面的查询在语法上可能是等价的:

SELECT t0.attr_73102_ AS attr_73270_ 
FROM object_73130_ f1 
LEFT JOIN (object_73200_ o
  INNER JOIN master_slave m ON m.id_slave_field = o.id
  INNER JOIN object_73101_ t0 ON t0.id = o.attr_73206_)
ON f1.id = o.id_field
WHERE m.id_object IN (73130,73290) 
AND m.id_master IN (73200,73354) 
GROUP BY o.id_field
ORDER BY o.id_order;

关于mysql - 如何优化导致性能非常低的连接，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18562251/