建立关注者/关注 MySQL 数据库的最佳实践

Question

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

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

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

'ID' 是主要的，'username' 和 'email' 是唯一的和索引。

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

| ID | feed_to_show_in_home |

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

| ID | followers_count | following_count |

并且至少存储了谁跟随谁的真实追随者网络表：

| ID | following |

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

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

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

Answer 1

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

长答案：要进行更多缩放，请考虑以下内容...

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

• 1:1 关系中的两个表。
• 存储可以计算的东西。

我说“通常”是因为您正在处理需要例外的情况。但首先，让我提一下其他一些模式设计：

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_INCREMENT，因为有一个完美的PK。 并且查询将运行得更快，我们将在一分钟内看到。
• 在您拥有 10 万关注者之前，COUNT查询“足够快”，因此您无需预先计算计数。

如果您要计算“喜欢”的数量，那么谨慎的做法是为频繁更新的值创建一个单独的表格。这样的表与 User 表是 1:1 的，因此违反了第一个不好的做法。这里的理由是将Like 中非常高的写入活动与其余“用户”信息中的低但重要的读取活动分开。