mysql - 对于变长的数据库表，什么是好的解决方案？

Question

我将使用特定场景描述问题:

假设您创建了一个用户可以注册的网站，
注册后，他们可以互相发送私信。

本网站使每个用户都可以维护自己的 friend 列表，
并维护一个被阻止的用户列表，他不想从中收到消息。

现在的问题:

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

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

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

所以我有两个问题:

1. 这个问题有哪些可能的解决方案？
   我不怕长数据库表，
   但我害怕包含这么多用户数据的数据库表，
   这意味着每次都需要扫描整个表，只是为了从中为特定用户提取几条记录。

2. 我有一个具体的解决方案，我想问一下:
   对于这个问题，我想到的一个解决方案是，每个注册到该网站的用户都会有自己的动态(和编程)为他创建的“迷你数据库”，
   这样，Friends 表和 Blocked Users 表将只包含他的记录。
   这使得扫描那些表变得非常容易，因为所有记录都是他的。
   这种想法是否存在于 MS-SQL Server 或 MySQL 等数据库中？如果是，它是否是所描述问题的良好解决方案？
   (每个用户都会为他创建自己的小型数据库，当然还有用于非用户特定的所有其他数据的主(公共(public))数据库)

谢谢大家

Answer 1

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

您是否尝试过任何一种阅读查询计划的方法来了解速度减慢的发生方式和位置？在做基础之前，不要只是增加内存或盲目尝试高级功能。

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

分区是 SQL Server 的一个很棒的功能，而在 2014 年你可能有数千个分区，你可能(除非你将每个分区放在一个单独的驱动器上)不会看到你正在寻找的大性能提升。

SQL Server 对表的响应时间非常快(尤其是对于具有数千万行的表(在您的情况下为用户表))。不要让主表变得太宽，响应时间会非常快。