数据库可扩展性：表大小和查询数量哪个更重要？答案

【问题标题】：Database scalability: Which is more important, size of table or number of queries?数据库可扩展性：表大小和查询数量哪个更重要？
【发布时间】：2011-09-05 00:58:40
【问题描述】：

我将以一个简化的 StackOverflow 系统为例。

虽然限制了某些功能，但可能会将问题和答案放在同一个表中：

(Django-esque pseudo-code)

QA table:
    parent = ForeignKey(self)
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

然后，要获取 ID 为 1 的问题的问题和答案，将对 id==1 或 parent==1 执行 SQL SELECT。缺点是 Answers 不使用 tags 和 title 字段

当然可以选择两张表：

Questions:
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

Answers:
    parent = ForeignKey(Questions)
    description = TextField()

这需要两个查询才能获得问题和答案。

本能说前者是一个可怕的想法，但我不知道为什么。

哪个更快、更具可扩展性？

【问题讨论】：

可扩展性远不止这些因素。服务器上的负载、并发客户端的数量、索引策略、缓存策略和许多其他因素都会影响它。这个问题真的不好回答。
这种情况下的答案很可能是“这取决于您使用的数据库 + 版本 + 索引（+ 数据库可用内存量） - 所以分析并找出” .两种结构都只需要一个查询来提取问题和答案，并且两种选择语句都可以通过连接来完成。
“失败是 Answers 不使用标签和标题字段”——是的。 所以不要那样做。 从“好的”规范化数据库设计开始。问题会来，解决方案也会来。从“良好的基础”开始将减少需要处理的问题的数量，并增加解决方案完全专注于实际问题而不是不必要地引入的机会。（只有在索引不能“选择”查询实际需要的行子集时，表的大小才非常相关。）

标签： sql database-design scalability scaling

【解决方案1】：

要直接回答您的问题，您的直觉是正确的。将实体（问题和答案）混合到一个表中几乎总是一个坏主意。从逻辑上讲，它们是 2 个独立的实体，在物理上它们应该保持独立。

您的第二个解决方案是正确的。使用索引和外键通过问题 ID 链接 2 个表将允许您选择任何问题的所有答案。这将更快，并且可以更好地扩展，并且对于将来必须使用该结构的任何人都更容易理解。

【讨论】：

【解决方案2】：

我认为这里没有一个好的答案。以我的拙见，最好的答案是视情况而定。例如，如果您将问题和答案放在两个单独的表格中，您就会将自己限制在该模型中。例如，您不能在某种层次结构中有子答案或子问题。这可能没问题，但不一定适合您的环境。

就个人而言，我会尝试查看情况和数据。如果与答案相比，我必须存储关于问题的不同数据（或者如果我必须将同一列用于两个不同的目的），我会创建两个表。如果数据相同并且将始终相同，我将其存储在一个表中。

然而，除了这个有限的数据库模式视图之外，还有一个需要考虑的更大的图景。例如，什么最适合您的存储引擎？什么最适合您的硬件？用于备份？归档？性能和可扩展性将取决于许多因素。这是一个开始讨论的好地方，但这只是冰山一角。

【讨论】：