我正在构建一个应用程序，以支持200,000多个注册用户，并希望为每个用户添加一个地址簿功能，以导入他们自己的联系人（例如姓名，地址，电子邮件等）。每个用户将拥有c.150个不同的联系人，每个记录有10-15个字段。
我的问题很简单：考虑到每个用户的用户数量和联系人数量，最好是为每个用户的地址簿创建单独的表，还是为该关联的用户帐户创建user_id查找的单个表？
如果您能从性能角度解释原因，那将非常感激。
更新：规格
在回答评论中的问题时，以下是规范：我将在AWS RDS（http://aws.amazon.com/rds）上托管数据库。它主要是一个沉重的读取负载，而不是写入。访问write时，它将是INSERT和UPDATE之间的平衡，几乎没有删除。想象一下您查看和编辑自己的地址簿的次数。
由于
答案 0 :(得分：1)
响应规格的具体答案 一个联系人数据表，一个索引的外键列返回给用户。查找特定用户的联系人will require about 3 seeks，这是一个相对较小的数字。如果搜索是你的瓶颈，请使用SSD。
如果您的15列各有100个字节，并且您有150个，那么每个用户的最大数据传输量为256k。我会将应用程序设计为仅预先显示所需的联系人数据（比如前3个最有用的联系点 - 姓名，电子邮件，电话），然后在特定联系人请求时提取更多细节。在（大概）极少数情况下，当您需要所有联系人的信息（例如导出为CSV）时，如果您具有该访问权限，请考虑SELECT INTO OUTFILE。 vCard输出效率较低：你需要获取所有数据，然后填入正确的格式。如果您经常需要vCard，请考虑在更新数据库时使用vCard（缓存方法）。
如果仍未达到效果要求，请考虑partitioning on the user id。
一般回答
围绕KISS和您的性能要求设计架构，同时记录可伸缩性计划。
在这种特殊情况下，数据量不会让我觉得极端，所以我会将KISS倾向于一张桌子。但是，我不清楚你将要进行的查询类型 - JOIN是通常的性能需求，而不是直接的SELECT。另外我不清楚你的SELECT / UPDATE混音。如果阅读量很大且由用户使用，则可以使用单个表格。
无论如何，如果在实施后您发现性能要求未得到满足，我建议您考虑通过更快的硬件，不同引擎进行扩展（例如MyISAM与InnoDB - 了解您的特定MySQL版本的差异！） ，物化视图或分区（例如，在相应用户名的第一个字母周围 - 假设你有一个）。
答案 1 :(得分：0)
拥有单个表格，但分区表格由用户的起始字母表组成，例如以A开头的所有姓氏将被加载到1个分区中。所有以B开头的名称都将加载到另一个分区中。
您还可以进行一些分析以找到正确的分发密钥。
答案 2 :(得分：0)
我不是DBA，但我建议您正确地规范化数据库，添加索引等，而不是为了满足可能存在的性能问题。如果可能，让DBA检查您的架构。我不认为20,000个用户过多。所有200,000个用户都不可能在处理一个人输入所用的相同x毫秒内点击更新按钮。只有少数人会在任何时间登录，其中大部分将填写数据或盯着网页上的现有数据而不是点击该更新按钮。如果碰巧他们中的一群人同时击中了它，那么可能会有性能等待而不是崩溃。这是您的架构的粗略布局（里程可能会有所不同）：
用户
long userID主键
字符串firstName
字符串lastName
联系
long contactID主键
long userID外键
字符串firstName
字符串lastName
地址
long addressID主键
long contactID外键