多列vs少表-性能明智

是的，我知道数据规范化应该是我的首要任务。

1. 我有一个表，65列存储与列车辆数据：used_vehicle，color，doors，mileage，price等等，总共65。
2. 现在，我可以除以和有一个Vehicle表，VehicleInterior，VehicleExterior，VehicleTechnical，VehicleExtra（全一到一个与主Vehicle表）。

假设我有大约500万行（车辆）。

在SELECT带有WHERE子句的情况下：搜索效果会更好（两种情况至少都在上索引IDs）：

1. Vehicle 65列的表格或
2. Vehicle表与JOINS其他四个表（均具有500万行）一起返回与Vehicle？相关的所有数据

（根据数据库引擎，考虑PostgreSQL和/或MySQL）。

真的很欣赏您以前的经验中得到的任何详细见解吗？

假设我们正在讨论所有表之间的1：1关系。

整体存储实际上总是（基本上）与便宜的单个表，而不是多个表在1：1的关系。每行有28个字节的开销，通常还有几个字节用于额外的填充。并且您需要在每个表中存储PK列。并且在每个这些列上都有一个单独的（冗余）索引。大小对于性能至关重要。

如果大多数行中的许多列为NULL，则甚至是这样，因为NULL存储非常便宜：

• 配置PostgreSQL以获得读取性能

检索所有列时，单个表的速度明显快于连接在一起的5个表的速度。这也要简单得多。如果不是所有表中都没有所有行，则五个表可能很难连接。使用WHERE针对单个表的条件，可以很容易地将其他表附加到LEFT JOIN。如果您有多个表的谓词，那么它就不那么简单了……

垂直分区 仍然可以提高某些查询的性能。例如，如果您有90％的查询在65个可用查询中检索到相同的5列，那么对于只包含这5列的表来说，这样做会更快。

• 查询期间从磁盘检索到什么？（我的答案）

OTOH，您也许可以通过“覆盖”索引来满足对少数选定列的此类查询，从而允许仅索引扫描。

垂直分区的另一种选择：如果您仅在几列上进行大量更新，而其余​​几乎不变。在这种情况下，拆分行可能会便宜得多，因为Postgres会为每次更新编写新的行版本。离线存储大值（“ TOASTed”）有例外。更多细节：

• 查询期间从磁盘检索到什么？（丹尼尔的答案）
• 更新另一个表中的所有列

这实际上取决于整体情况。如有疑问，请使用拥有单个桌子的简单解决方案，尤其是当它很好地描述现实时：在您的示例中，这些都是汽车的属性，并且在一起就有意义。

在单个表上进行选择应该总是更快。一旦找到您的车辆，您便已经拥有所有详细信息。

但是，您将失去标准化的效率。例如，如果一辆汽车有许多具有不同选项的模型。

这是所有汽车的参考分贝吗？还是二手车清单？是否会有许多具有相同选项的相同品牌/型号的示例？

编辑：我应该把我的答案限定为通用rdbms而不是特定于postgres。我遵照@Erwin针对postgres的详细答案