当我们创建涉及一对多关系的数据库设计时，随着关系中数据的增长，存在潜在的性能损失风险。
例如，让我们采用一个简单的一对多关系，涉及两个表。
[User] 1 ----- m [Friends]
一个用户可以有很多朋友。一个常见的设计是两个表，其中一个包含所有用户，另一个包含该用户的所有朋友，用户 id 作为 Friends 中的外键。
但从技术上讲，随着用户数量的增长，以及随之而来的好友数量的增长，检索用户好友列表将会对性能产生影响。
有没有设计模式可以解决这类问题，还是现阶段我们必须依靠计算能力来维持性能？
【问题讨论】：
标签： sql-server database database-design
但从技术上讲，随着用户数量的增长，以及随之而来的朋友数量的增长，就会有 检索用户朋友列表的性能影响。
是的。那又怎样？
使用索引。购买硬件。确切地说是这个顺序（看到不止一个过载的服务器，因为程序员从未读过http://use-the-index-luke.com/）。
您的问题不是问题，因为粗暴地说，当您拥有更多数据时，没有办法阅读更多数据。这就是为什么某些数据库需要每月 5 美元以上的廉价低端虚拟机，而且如今在数据库服务器中拥有 1 TB 的内存用于缓存并非闻所未闻。
基本上你说“我开店，我存库存。现在当我存更多库存时，我需要更多空间，我不能真正在早餐前独自处理工作，我该如何解决这个问题”和答案是 - 获得更多空间并雇用 ppl。 sql 中的答案是 - 获得更大的服务器。
除非你做了一些不聪明的事情，比如没有把正确的索引放在那里，就是这样。
一个低端服务器（8 核，每个 4 核的双 opteron，大约 5 年历史）在具有 6 核和 48gb 内存的虚拟机中，我在客户处使用它来聚合具有数亿个条目的行选定的结果（在 otf 表中，有 100 亿行并且还在增长），是的，我们有一个精心布置的磁盘子系统 (NEED IO)，RAM 有点不足，有时 CPU 会用尽。
但我无能为力。
拥有更多数据，您需要更强大的硬件。
使用索引，性能在 LOG(n) 上大致得到消息（取决于很多因素） - 所以它不会线性地 sloq。如果您跳过索引，它是线性的 - 表长的 2 倍，查询的 2 倍，并且生活在痛苦中。所以要胜任（尽管指标至少在基线形式中是非常基本的），然后将硬件扔到问题上。
没有其他解决方案。
【讨论】：
您可以在根据朋友表中的用户选择检索朋友列表时使用索引功能。
【讨论】：
在您认为性能不佳之前测试您的查询。
在您的测试环境中生成测试数据，运行您的查询，检查结果，调整您的查询，调整索引，检查天气或性能是否改善，重复直到满意为止。
【讨论】：