SQL / Postgres，大表与多表，如何进行性能测试？

Question

我正在开发一个 Postgres 数据库，其中有一些将一直被查询/访问的记录，并且它们具有无限量的可选“元数据”，这些数据将随着时间的推移而被收集。

为了说明这个想法，请考虑一个像全国汽车经销商网络这样的案例。你可以有一个像这样的表：

Vehicles
--------
id
type
status
location

几乎每个查询都需要这些信息。但是有一堆可选的额外信息，如品牌、型号、年份、里程、颜色、以前的所有者、MSRP、蓝皮书价值等。

这些都可能只是 Vehicles 表中的字段，也可能是其他表中的字段，例如 VehicleMetadata，外键指向特定车辆。

作为一个 SQL 外行，我真的不知道在一个表或两个表中执行此操作会有什么不同。我有兴趣了解：

1. 作为 db 专家，您将如何比较和测试这些不同的架构选项并确定哪个表现最佳？

2. 一种方法还是另一种通常被认为更传统或标准的做法？

谢谢！

Answer 1

因此，对于与您的问题极为相关的背景阅读，请参阅 this link on database normalization。

让我简化一下，无论您将所有数据存储在一起还是存储在单独的表中，归结为在查询性能与数据冗余之间进行权衡。我不能告诉你应该怎么做，因为我不知道你的查询负载，但这里是如何考虑的。

冗余和查询性能之间的权衡

您拥有所有这些额外的可选字段，例如 make ("Honda")。如果您在每条汽车记录中存储make=Honda，您将存储本田数千或数百万次，因为本田非常受欢迎。另一方面，如果您将make 拆分到一个单独的表中，则可以存储一次Honda 并通过主键/外键引用它。您还可以将其他数据附加到该本田值。因此，如果您将其作为单独的表进行，则每次需要本田“事实”时，都必须进行联接。关系数据库擅长连接，但它们仍然比将数据存储在表中要慢。执行此连接的好处是您将大大减少数据库中的冗余量。如果本田被收购，更新其名称会更容易，并且您的数据库将需要更少的存储空间。

因此，此示例 (make=Honda) 可能会与您的许多其他属性重复。从纯理论的角度来看，最好标准化您的数据库，并尽可能减少/消除冗余。从实际的角度来看，您的查询必须运行良好，并且首先必须合理编写。因此，对于大多数人来说，正确的答案是平衡这两种观点与您的查询负载如何工作的知识。

良好的默认建议

作为基本建议，请查阅那些标准化材料；我建议您将 3NF（第三范式）作为您所做的大多数事情的默认基线，但需要注意的是，您可以根据用例和查询负载对此做出妥协并更多（或更少）规范化。一般来说，您会发现高度非规范化的表（您不进行连接，一个表中的所有内容）对于大型查询（假设一个良好的索引策略）表现更好

性能测试

一般来说，我不会这样做，除非你有真正的核心理由来证明你需要最高性能。有句老话“过早的优化是万恶之源”，它也适用于数据库。要诚实地进行性能测试，您必须正确处理很多事情，并确保正确调整数据库的许多方面。设置这个实验以获得好的数据并不简单，大多数人发现在数据库变得非常庞大之前，他们无论如何都不需要这样做。