mysql - 构建关注者/关注 MySQL 数据库的最佳实践

Question

我将为社交网络风格的网站构建一个 MySQL 数据库，其中用户关注其他用户，然后从他们关注的用户那里获取更新。

我的数据库由一张包含用户基本信息的表组成:

| ID | username | password | email | ... other few columns | 

“ID”是主要的，“用户名”和“电子邮件”是唯一的和索引。

然后我有一个包含用户提要的表格，只有当其他用户关注它时才应该显示，“ID”始终是主要的:

| ID | feed_to_show_in_home |

然后是一个包含关注者统计信息的表格，以加快用户个人资料页面的速度:

| ID | followers_count | following_count |

并且至少存储了谁关注谁的真实关注者网络表:

| ID | following |

在此表中，“ID”和“关注”都是主要的，因为一个用户只能关注另一个用户一次。

现在我想问一下，从性能的角度来看，我的结构是否良好。我尤其担心如何检查一个用户是否正在关注另一个用户、如何停止关注某个用户，以及如何仅在我关注该特定用户时才显示提要。

在任何一种情况下，我想到的解决方案都是始终扫描整个表长度，但我认为这不是一个好的选择，因为该数据库计划存储超过 10,000 个用户。

Answer 1

简短的回答:10,000 个太少了，任何设计都“足够好”。

长答案:为了更大的扩展性，请考虑以下...

这些设计通常是不好的做法:

• 两个表存在 1:1 关系。
• 存储可以计算的内容。

我说“通常”是因为您正在处理需要异常(exception)的情况。但首先，让我提一下其他一些架构设计:

CREATE TABLE Follow (
    er ...,  -- user id of the the follower
    ed ...,  -- user id of the the followed
    PRIMARY KEY(er, ed),
    INDEX(ed, er)
) ENGINE=InnoDB;

SELECT COUNT(*) FROM Follow WHERE ed = ?; -- number of followers for `ed`.
SELECT er FROM Follow WHERE ed = ?  -- list of such followers
(Similarly for the flip direction)

注释:

• 没有代理AUTO_INCRMENT，因为有一个完美的PK。 而且查询将运行得更快，我们很快就会看到。
• 在您拥有 10 万关注者之前，COUNT 查询“足够快”，因此您无需预先计算计数。

如果您要计算“喜欢”的数量，明智的做法是为经常更新的值建立一个单独的表。这样的表与 User 表是 1:1，从而违反了第一个不好的做法。这里的理由是将 Like 中非常高的写入事件与“用户”其余部分中低但重要的读取事件分开信息。