我将使用特定方案描述问题：
想象一下，您创建了一个用户可以注册的网站， 注册后，可以互相发送私信。
此网站可让每位用户维护自己的好友列表， 并且还维护一个阻止用户列表，他不希望从中获取消息。
现在出现问题：
想象一下这个网站吸引了数百万用户， 并且假设每个用户在Friend表中有大约10个Friends，在Blocked Users表中有10个Blocked Users。
好友列表表和被阻止的用户表将变得很长， 但更糟糕的是， 每当有人想要向另一个人发送消息时，＆＃34; X＆＃34;， 我们需要遍历整个Blocked Users表，并查找用户＆＃34; X＆＃34;定义 - 他阻止的人。
这＆＃34;扫描＆＃34;一个长数据库表对我来说似乎有点低效。
所以我有2个问题：
1）这个问题可能有哪些解决方案？ 我不怕长数据库表， 我担心包含这么多用户数据的数据库表，这意味着每次都需要扫描整个表，只是为了从特定用户那里提取一些记录。
2）我想到的具体解决方案，我想问一下：
我对此问题的一个解决方案是，每个注册到网站的用户都将拥有自己的＆＃34;迷你数据库＆＃34;为他创造， 这样，好友表，一个被阻止的用户表，将包含仅限他的记录。
这使得扫描这些表非常容易，因为所有记录都适合他。
这个想法是否存在于MS-SQL Server或MySQL等数据库中？ 如果是，对于所描述的问题，这是一个很好的解决方案吗？ （每个用户都将为他创建自己的小型数据库，当然还有主要（通用）数据库，用于非用户特定的所有其他数据）
谢谢大家
答案 0 :(得分：2)
我会等待分区和创建迷你数据库的想法。您的数据库是否在不同的RAID驱动器上安装了数据，日志和临时文件？您是否在搜索和连接列上的表和索引上有聚簇索引？
您是否尝试过任何类型的查询计划来查看减速的发生方式和位置？在进行基础测试之前，不要盲目地添加内存或尝试高级功能。
创建单独的数据库将成为维护的噩梦，对于您将来可能希望做的查询类型（对于所有用户......）来说将是一项挑战。
分区是SQL Server的一个很棒的功能，虽然在2014年你可能有数千个分区（除非你把每个分区放在一个单独的驱动器上），但是看不到你正在寻找的大的性能提升。
SQL Server对表的响应时间非常快（特别是对于具有10百万行的表（在您的情况下是用户表））。不要让主表太宽，响应时间会非常快。
答案 1 :(得分：1)
马上我的第一个想法是：
https://msdn.microsoft.com/en-us/library/ms188730.aspx
分区可以让您将其分解为更易于管理的部分，并且可以扩展。关于如何分解，你必须做出一些选择，但我相信这是你正确的道路。
关于表格扫描，如果您有正确的索引，您应该在查询中获取搜索。您将需要查看执行计划以确定这一点。
至于为每个用户设置mini-DB，这是你可以通过分区完成的。
答案 2 :(得分：1)
Mini-Database是一个明确的禁区。 UserID和BlockedUserID两列INT列并且具有正确的索引，如果您使用此方法，则不会出错明智地写你的问题:) 答案 3 :(得分：1)
我曾经为社交网络系统做过一次。也许你可以寻找你的规范化。那时我得到了一张[关系]表，它就是
UserAId Int
UserBId Int
RelationshipFlag Smallint
有100万用户，每个用户有10个“朋友”，该表有1000万行。这不是问题，因为我们在列上放置索引，它可以立即检索所有“相关”用户B的列表到特定用户A.
仔细查看您的架构和索引，如果它们没问题，那么DB不会遇到问题。
修改
我同意@ M.Ali
每个用户的迷你数据库都是明确的禁区。
恕我直言，如果你坚持基本并以正确的方式实施，你就没事了