创建庞大SQL表的最佳实践

Question

我想为50个州中的每个州创建一个关于“用户”的表格。每个州都有大约2GB的数据。哪个选项听起来更好？

1. 创建一个名为“users”的表，其大小为100GB或
2. 创建50个名为“users_ {state}”的单独表格，每个表格大小为2GB

我正在研究两件事：表现和风格（最佳实践）

我也在AWS上运行RDS，而且我有足够的存储空间。有什么想法吗？

编辑：从它的外观来看，我不会同时需要来自多个状态的信息（即如果我使用选项2则不需要经常连接表）。这是一个常见的用例：前端将状态id传递给后端，并且基于该id，我需要从db查询有关指定状态的数据，并将数据返回到前端。

Answer 1

• 50个州是否真正独立于您的业务逻辑？这意味着您的查询大多数时间只需要在一个给定状态下运行？如果是这样，按州拆分可能是一个不错的选择。在这种情况下，您只需要加入相对较少的查询，例如报告查询等。

编辑：根据您最近的编辑，第一个选项是我推荐的路线。当不需要连接时，您将从表分区中获得更好的性能，并且像这样使用较小的分区表还有许多其他好处。

• 如果您的查询通常需要加入大多数州，那么您绝对不应该像这样分区。你最好使用一个大表，只需构建性能所需的相应索引。大多数现代企业数据库解决方案能够处理从2GB到100GB的边际性能影响（正确索引）。

• 但是如果您的查询平均需要加入来自少数几个州的结果（比如不超过5-10个），那么最佳解决方案是更复杂的灰色区域。您可能会通过加入从分区表中提取更好的性能，但它可能会使代码和/或查询（以及所有即将到来的维护）明显变得更加复杂。

请注意，我的回答假定更常见的访问频率细分：高读取，适度更新，低创建/删除。此外，如果主要关注大数据的性能，您可能需要检查NoSQL（例如，Amazon AWS DynamoDB），但这将是一种侵入性的，与关系系统的基本背离。但NoSQL的性能优势绝对是戏剧性的。

Answer 2

在不了解更多模型的情况下，任何人都难以对性能等进行判断调用。但是，从数据建模的角度来看，在考虑规范化模型时，我希望看到一个User表。一个列（或复合键的列），用于将外键保存到状态表。如果用户可能与多个状态相关联，我希望创建另一个表（UserState），这将保留用户和状态的外键，以及有关该关系的任何其他信息（例如，启动和时间切片的结束日期，显示用户和州关联的时间段。）

如果您发现存在性能问题，而不是将数据拆分为单独的表，则可以使用分区按状态拆分用户数据，同时将其保留在单个表中。我没有使用MySQL，但很快谷歌就如何在MySQL中实现分区提供了大量的参考信息。

在尝试构建和运行此功能之前，我不会认为您是否存在性能问题。如果这样做，按照上述设计，您可以在事后应用分区，而无需更改前端查询。此外，如果事实证明你做同时需要多个州的信息，这个解决方案不会有问题，并且如果你需要的话，不会让你感到悲伤通过State以外的某些方面来看待User。