创建大型 SQL 表的最佳实践答案

【问题标题】：Best practices for creating a huge SQL table创建大型 SQL 表的最佳实践
【发布时间】：2015-08-21 17:36:49
【问题描述】：

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

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

我在看两件事：性能和风格（最佳实践）

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

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

【问题讨论】：

这在很大程度上取决于您将如何访问数据，这个问题太宽泛，没有更多细节。

标签： mysql database database-design coding-style large-data

【解决方案1】：

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

与其将数据拆分到单独的表中，如果您发现存在性能问题，您可以使用分区按状态拆分用户数据，同时将其保留在单个表中。我不使用 MySQL，但快速的 Google 找到了大量关于如何在 MySQL 中实现分区的参考信息。

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

【讨论】：

【解决方案2】：

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

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

如果您的查询通常需要连接大多数州，那么您绝对不应该像这样进行分区。最好使用一张大表，只需构建性能所需的适当索引。大多数现代企业数据库解决方案都能够很好地处理从 2GB 到 100GB 的边际性能影响（通过适当的索引）。
但是，如果您的查询平均需要连接来自少数几个状态的结果（比如不超过 5-10 个左右），则最佳解决方案是一个更复杂的灰色区域。您可能能够通过连接从分区表中提取更好的性能，但它可能会使代码和/或查询（以及所有即将进行的维护）变得更加复杂。

请注意，我的回答假设了更常见的访问频率故障：高读取、适度更新、低创建/删除。此外，如果大数据的性能是您最关心的问题，您可能想要查看 NoSQL（例如，Amazon AWS DynamoDB），但这将是对关系系统的一种侵入性和根本性的背离。但是 NoSQL 的性能优势绝对是显着的。

【讨论】：