Question

当我们创建涉及一对多关系的数据库设计时，随着关系中的数据增长，存在性能损失的潜在风险。

例如，让我们采用涉及两个表的简单的1对多关系。

[User] 1 ----- m [Friends]

用户可以拥有很多朋友。一个常见的设计是两个表，其中一个包含所有用户，另一个包含该用户的所有朋友，其用户ID为Friends中的外键。

但从技术上讲，随着用户数量的增长以及随后朋友数量的增长，检索用户朋友列表会对性能产生影响。

是否有解决此类问题的设计模式，或者在此阶段我们必须依靠计算能力来维持性能？

Answer 1

但从技术上讲，随着用户数量的增长，以及随后朋友数量的增长，那么就会有性能影响检索用户朋友列表。

是。那么什么？

使用指数。买硬件。精确到这个顺序（看到多个重叠的服务器，因为程序员从来没有读过http://use-the-index-luke.com/）。

你的问题不是问题，因为粗暴地说，当你有更多的数据时，无法用更多的数据进行读取。这就是为什么某些数据库每月需要超过5美元的廉价低端虚拟机的原因，而现在数据库服务器中有一个TB的内存用于缓存是不可能的。

基本上你说“我开店，我保留库存。现在当我保留更多库存时，我需要更多空间，我不能真正独自处理工作，我怎么能解决这个问题”和答案是 - 获得更多空间并雇用人才。在sql中的答案是 - 获得更大的服务器。

除非你做了一些不聪明的事情，比如没有把正确的指数放在那里，那就是它。

我在客户中使用的一个下端服务器（8个内核，双核，每个4核，大约5年），用于聚合具有数亿条目的行选择的结果（从表格中排除了100亿行并且正在增长）是的，我们需要仔细布置光盘子系统（NEED IO），RAM有点短，有时可以最大化CPU。

但我无能为力。

有了更多数据，您需要更强大的硬件。

对于索引，执行在LOG（n）上大致得到字（取决于很多因素） - 所以它不是线性的。如果你跳过索引它是线性的 - 2倍长表，2倍长查询和生活在痛苦中。所以要胜任（至少在基线形式的指数是非常基本的），然后抛出硬件问题。

没有其他解决方案。

Answer 2

您可以在根据朋友表中的用户选择检索朋友列表时使用索引功能。

Answer 3

在假设性能不佳之前测试您的查询。

在测试环境中生成测试数据，运行查询，检查结果，调整查询，调整索引，检查天气或不改善性能，重复直到满意为止。