对于变长的数据库表有什么好的解决方案？

Question

我将使用特定场景描述一个问题：

想象一下，您创建了一个用户可以注册的网站，
并且在他们注册后，他们可以互相发送私信。

该网站使每个用户都可以维护自己的好友列表，
并维护一个阻止用户列表，他不希望从中获取消息。

现在的问题：

想象一下这个网站拥有数百万用户，
我们还假设每个用户在 Friends 表中有大约 10 个 Friends，在 Blocked Users 表中有 10 个 Blocked Users。

Friends 列表表和 Blocked Users 表将变得很长，
但更糟糕的是，每当有人想向另一个人“X”发送消息时，
我们需要查看整个 Blocked Users 表，并查找用户“X”定义的记录 - 他阻止的人。

每次从一个用户向另一个用户发送消息时，这种对长数据库表的“扫描”对我来说似乎效率很低。

所以我有两个问题：

这个问题有哪些可能的解决方案？
我不怕长数据库表，
但我害怕包含这么多用户的数据的数据库表，
这意味着每次都需要扫描整个表，只为该特定用户从中提取一些记录。
我心中有一个具体的解决方案，我想问一下：
对于这个问题，我想到的一个解决方案是，每个注册到网站的用户，都会为他动态（和以编程方式）创建自己的“迷你数据库”，
这样， Friends 表，即 Blocked Users 表，将只包含他的记录。
这使得扫描这些表变得非常容易，因为所有记录都是他的。
这个想法是否存在于像 MS-SQL Server 或 MySQL 这样的数据库中？ 如果是，它是否是所描述问题的好解决方案？
（每个用户都会为他创建自己的小型数据库，当然还有所有其他非用户特定数据的主（公共）数据库）

谢谢你们

Answer 1

我会等待分区和创建迷你数据库的想法。 您的数据库是否与不同 RAID 驱动器上的数据、日志和临时文件一起安装？ 表上有聚集索引，搜索列和连接列上有索引吗？

您是否尝试过阅读查询计划以了解速度下降的方式和位置？ 在做基础之前，不要只是添加内存或盲目尝试高级功能。

创建单独的数据库将成为维护的噩梦，并且执行您将来可能喜欢执行的查询类型（针对所有用户......）将具有挑战性。

分区是 SQL Server 的一项很棒的功能，虽然在 2014 年您可以拥有数千个分区（除非您将每个分区放在一个单独的驱动器上），但您可能不会看到您正在寻找的巨大性能提升。

SQL Server 对表具有非常快的响应时间（特别是对于具有 10 几百万行的表（在您的情况下是用户表））。 不要让主表太宽，响应时间会非常快。

Answer 2

马上我的第一个想法是：

https://msdn.microsoft.com/en-us/library/ms188730.aspx

分区可以让您以可扩展的方式将其分解为更易于管理的部分。 关于如何打破它，你必须做出一些选择，但我相信这对你来说是正确的道路。

关于表扫描，如果您有适当的索引，您应该在查询中得到搜索。 不过，您将需要查看执行计划以确保了解这一点。

至于为每个用户拥有迷你数据库，这是您可以通过分区完成的。

Answer 3

每个用户的Mini-Database是一个明确的禁区。
另外附注一个单独的表，仅包含两列UserID和BlockedUserID它们都是INT列并且具有正确的索引，如果您明智地编写查询，则这种方法不会出错:)
查看表分区，具有良好索引的规范化数据库也会有所帮助。
此外，如果您能负担得起使用上一点中描述的表模式进行 Enterprise License 表分区，将使其成为一个非常好的查询友好的数据库模式。

Answer 4

我为社交网络系统做过一次。 也许你可以寻找你的归一化。 当时我得到了一个 [Relationship] 表，它刚刚得到

UserAId  Int
UserBId  Int
RelationshipFlag  Smallint

有 100 万用户，每个用户有 10 个“朋友”，该表有 1000 万行。 不是问题，因为我们在列上放置了索引，它可以立即检索到特定用户 A 的所有“相关”用户 B 的列表。

仔细查看您的架构和索引，如果它们没问题，那么您的数据库就不会在处理它时遇到问题。

编辑

我同意@M.Ali

每个用户的迷你数据库是一个明确的禁区。

恕我直言，如果你坚持基本的并以正确的方式实施它，你就很好