mysql - 当 MySQL 不优化它们时，我应该避免加入吗？

Question

在大学 SQL 类(class)中，关系数据库都是关于表之间的 JOINS 的。所以我采用一般方法首先进行所有必要的 JOINS，然后选择数据，在需要时使用 WHERE 和 GROUP BY 进行过滤。这样代码和逻辑就很简单了。

但很多时候当事情变得比单个 LEFT JOIN 更复杂时，我的性能会很差。

今天我重写了 JOIN 查询，执行时间为 600 秒不同的方法:SELECT (SELECT ... WHERE ID = X.ID) FROM X和SELECT ... WHERE Y IN (SELECT ...)现在它在 0.0027 秒内完成。

我很沮丧，我在我加入的字段上使用索引，但性能很差......

Answer 1

LEFT JOIN 可能，但并不总是，强制首先查看“左”表。

JOINs(但不是 LEFT JOINs)加上接触 one 表的 WHERE 为优化器提供了强大的，靠谱，提示先看那个表。

JOIN，加上 WHERE 接触多个表——优化器有时会选择正确的“第一个”表，有时不会。

优化器通常从一个表中获取行(以它选择的最佳开始为准)，然后执行 NLJ(嵌套循环连接)。这意味着一次一行地进入下一张表。这种“影响力”需要一个好的索引。

IN ( SELECT ... )，在旧版本中非常不是最优的。现在，它可能变成“半连接”，如 EXIST ( SELECT ... ) 并且非常高效。有时手动执行此操作是有益的。

“爆炸-内爆”击中了很多人。这是有 JOIN 和 GROUP BY 的地方。分组主要是为了分解连接创建的大量行。有时“派生”表可能是一个很好的优化。 (这是查询的手动重新表述。)

通常用于聚合的 LEFT JOIN 可以折叠成这样:SELECT ..., ( SELECT SUM(foo) FROM ... ) AS foos, ...，从而减轻爆炸内爆。

不理解“复合”索引的好处可能是这个论坛上最常见的问题。

我要继续说下去吗？我怀疑我是否涵盖了超过 1/4 的案例。所以，我同意@leftjoin。

这里有一些简单的提示:http://mysql.rjweb.org/doc.php/index_cookbook_mysql