MySQL关于用户关注粉丝表设计方案的思考

方案一

• follow(关注关系表)

字段名	类型	索引	注解
id	primaryKey()
user_id	integer()->unsigned()->notNull()	normal	用户
followed_user	integer()->unsigned()->notNull()		关注的人的id
status	smallInteger()->unsigned()->defaultValue(1)		关注状态:是否取消关注等
created_at	integer()->unsigned()->notNull()	normal
updated_at	integer()->unsigned()->notNull()	normal

用户每关注一个人，都会在表中添加一条数据

优点：

1.设计简单，方便查询
2.可以区分关注的每一个人进行特殊处理（例如，不同人的关注事件，是否互粉，特别关注等），方便扩展
3.好写代码。

缺点：

当用户量大时表数据量会非常庞大，因此必需要采用水平分表的方式将用户分散到多个表。

例如，有10万用户，ID为1~10000的用户放在表1(follow_1), ID为10001~20000的用户放在表2(follow_2), 以此类推。

然而分表后又会面临另一个问题,当被关注者依照多个表反查自己的粉丝时将会非常麻烦。因此需要再建一个粉丝表：

• fans(粉丝表)

字段名	类型	索引	注解
id	primaryKey()
user_id	integer()->unsigned()->notNull()	normal	用户
follower	integer()->unsigned()->notNull()		粉丝
status	smallInteger()->unsigned()->defaultValue(1)		关注状态:是否取消关注等
created_at	integer()->unsigned()->notNull()	normal
updated_at	integer()->unsigned()->notNull()	normal

此数据表依然需要做水平分表处理。

方案二

• follow(关注关系表)

字段名	类型	索引	注解
id	primaryKey()
user_id	integer()->unsigned()->notNull()	唯一	用户
followed_user	text		关注的人
follower	text		粉丝
created_at	integer()->unsigned()->notNull()	normal
updated_at	integer()->unsigned()->notNull()	normal

以json格式记录每个用户关注的人和粉丝

优点：

1.每个用户只有一条记录
2.方便查询

缺点：

1.当粉丝数或关注的人数过大时，followed_user 和 follower 字段的数据长度会非常大，当用户关注的人或者粉丝数达到十万级别时，一条数据的数据量将会达到 兆 级别，将会极大地降低mysql的查询和php数据处理的效率。

2.每一次使用该表时都要将整条数据取出进行计算,对资源耗费太过严重。

方案三

使用redis的Hash数据类型

Redis hash是一个string类型的field和value的映射表。
Redis 中每个 hash 可以存储 232 - 1 键值对（40多亿）。

每个用户分一张hash表,表名为用户id（可加前缀或后缀）

用户每关注一个人，便在hash表中添加一条数据

field: 关注用户的id

value：关注时间

• user_1

field	value
2	1483423443
3	1483423445
13	1483423440
...	...

• user_2

field	value
1	1483423443
5	1483423445
10	1483423440
...	...

......

优点

1.查询处理速度快。

缺点

1.消耗服务器内存和CPU。最好使用一台单独的服务器来运行 Redis

2.数据查询，处理不如关系型数据库灵活。

3.开发步骤复杂，学习成本高。

CREATE TABLE relation (
id PRIMARY KEY AUTO_INCREMENT, //主键，自增
from_user_id big integer, // 用户 A 的 id
to_user_id big integer,// 用户 B 的 Id
rel_type enum(1,2) //关注数据
);

拉黑/粉丝/关注，在数据库里，存的都是一个映射关系的数字。比如，拉黑是 1，粉丝/关注是一个东西，是 2。那么，一条记录里的关键数据是：

• from_user_id // 本条记录是哪个用户发起

• to_user_id // 本条记录的接受方是哪个用户

• rel_type // 发起者对接受者，做了什么事情？存事情的类型

场景举例：

用户 A 关注用户 B

插入数据：

INSERT INTO relation (rel_type, from_user_id, to_user_id) VALUES(2, A.id, B.id)

用户 A 的粉丝数：

select COUNT(*) from relation 
where rel_type=2 and to_user_id=A.id;

黑名单同理。

这是按照你给出的表的方式处理的。我自己在做设计的时候，其实是给 关注/粉丝 建了一张表，黑名单又建一张表。按自己的需求和习惯来就好了，无所谓选哪种。