具有大量 LEFT JOIN-s 的 PostgreSQL答案

【问题标题】：PostgreSQL with lots of LEFT JOIN-s具有大量 LEFT JOIN-s 的 PostgreSQL
【发布时间】：2021-12-22 15:41:51
【问题描述】：

我的收藏有多种类型：猫、狗、鸟。如果它是猫，那么我需要加入与猫相关的表，与狗和鸟一样。

我最终得到了很多 LEFT JOIN-s，当表有很多记录时，性能会受到影响。

SELECT Animal.*, CatDetail1.*, CatDetail2.*, DogDetail1.*, DogDetail2.*, BirdDetail1.*, BirdDetail2.*
FROM Animal
LEFT JOIN CatDetail1 on CatDetail1.id = Animal.id
LEFT JOIN CatDetail2 on CatDetail1.id = Animal.id
LEFT JOIN DogDetail1 on DogDetail1.id = Animal.id
LEFT JOIN DogDetail2 on DogDetail2.id = Animal.id
LEFT JOIN BirdDetail1 on BirdDetail1.id = Animal.id
LEFT JOIN BirdDetail2 on BirdDetail2.id = Animal.id
ORDER BY Animal.sequence

我在想 View 可能会使它运行得更快，但没有官方文档支持这一点。

有没有办法减少 LEFT JOIN，使用更多的 INNER JOIN 来提高性能？

【问题讨论】：

如果你的表被正确索引，我认为你会有很好的表现
没有足够的细节。好的。垃圾笑话。您能否在问题中包含CREATE TABLE 语句以允许审查设计？这个 tableN 设计有可能改进。
它们不是实际的表，因为我正在寻求解决此类结构问题的概念性解决方案，例如人们通常/通常如何解决这种大量的左连接问题。
性能问题可能很复杂。这个例子需要具体。在大多数情况下，每个表都有一个主键，引用将采用外键（和约束）的形式。这两种键（通常）都会有关联的索引。但这并不总是能让您获得最佳性能。这将取决于问题未提供的详细信息以及有关要优化的查询的更具体的详细信息。
听起来像过早优化的服务器案例，因为您正在尝试在实际运行任何东西之前进行优化。因为“过早的优化是编程中所有邪恶（或至少是大部分）的根源。” （Donald Knuth，计算机编程的艺术，1968 年）。当时如此，今天仍然如此（也许更是如此）。在这种情况下，甚至可能会质疑设计。

标签： sql postgresql join

【解决方案1】：

如果需要外连接，则不能使用内连接。您显然需要在这里进行外部连接。

没有更好的方法来编写该查询，并且没有明显不同的方法来模拟您希望将不同类型的对象存储在一个表中的情况。

如果查询速度很慢，那就不足为奇了。毕竟，您需要七个表中的所有内容，并且希望对结果进行排序。如果表很大，则需要一段时间。

视图在这里没有任何区别，因为视图只是一个命名的 SQL 语句，并且在执行查询时视图名称将被其定义替换。

您应该问自己的问题是，您是否真的需要七张桌子中的所有东西。也许您不需要所有列？也许您不需要所有行？

【讨论】：