许多列 vs 少数表 - 性能明智

Question

是的，我知道数据规范化应该是我的首要任务（因为它是）。

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）。

真的很感激您从以前的经验中可能获得的任何详细见解吗？

如果有的话，更新将很少见，并且选择将主要针对搜索结果列表的所有列（车辆详细信息页面）和主要信息（几列），实际上也许最好的解决方案是两个表：一个包含主要信息（很少列）和另一个表以及其余的列。

Answer 1

假设我们谈论的是所有表之间的 1:1 关系。

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

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

• 为读取性能配置 PostgreSQL

在检索所有列时，单个表比连接在一起的 5 个表快得多。它也简单得多。如果并非所有表中都存在所有行，则连接五个表可能会很棘手。对于WHERE针对单个表的条件，很容易将其他表附加到LEFT JOIN. 如果您在多个表上有谓词，那就不是那么简单了......

垂直分区 仍然可以提高某些查询的性能。例如，如果 90% 的查询从 65 个可用列中检索相同的 5 个列，那么使用仅包含这 5 个列的表会更快。

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

OTOH，您可能能够通过“覆盖”索引来满足对几个选定列的此类查询，该索引允许仅索引扫描。

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

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

这实际上取决于完整的情况。如果有疑问，请采用拥有一张桌子的简单解决方案，特别是如果它很好地描绘了现实：在您的示例中，这些都是汽车的所有属性，并且在一起是有意义的。