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

一、数据结构分析
用户关注粉丝是一个多对多的数据模型，分析对象的数据特征，我们给每个用户设计一个关注者属性和粉丝属性，用于存储用户的关注者id和粉丝id，如用户1：

$arr1 = [ 'follow' => '[2,3,4], 'fans' => [4,5,6], ]

二、用户逻辑关系梳理
在用户关注粉丝模型中，有两种常见场景：
1.查看自己的粉丝或者关注列表：
这种情况下最多会出现三种关系：
其中1表示仅为本人所关注的人，2表示仅为本人的粉丝，3表示互粉

2.查看别人的粉丝或者关注列表：
此时是以别人的粉丝或关注者与自己的关系进行判定：

其中find表示别人的粉丝或关注列表，在这里统称为other，1表示other是本人所关注的，2表示other与本人互粉，3表示other是本人的粉丝，4表示和本人没有任何关系

三、数据库设计

CREATE TABLE `tb_vip_follow` ( `id` bigint NOT NULL AUTO_INCREMENT, `vip_id` bigint DEFAULT '0' COMMENT '用户ID(粉丝ID)', `followed_vip_id` bigint DEFAULT '0' COMMENT '关注的用户ID', `status` tinyint(1) DEFAULT '0' COMMENT '关注状态(0关注 1取消)', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '修改时间', PRIMARY KEY (`id`), UNIQUE KEY `vip_followed_indx` (`vip_id`,`followed_vip_id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='会员关注关系表';

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

用户1关注了用户2，用户3； 用户2关注了用户1，用户3和用户4； 用户1有粉丝用户2； 用户2有粉丝用户1； 用户3有粉丝用户1，用户2； 用户4有粉丝用户2； 用户1和用户2互粉。

四、应用
这里为了省事，就没有考虑status字段，实际应用中，一定要补上，另外在关注之前记得要先查询是否存在取关，存在取关时只需要更新status字段

1.查看自己的粉丝或者关注列表：
以followed_vip_id字段查询，可以获取粉丝列表，以vip_id字段查询，可以获取关注者列表。

如查找用户1的粉丝：

select vip_id from tb_vip_follow where followed_vip_id = 1

如查找用户1的关注：

select followed_vip_id from tb_vip_follow where vip_id = 1

2.查看别人的粉丝或者关注列表：
查看别人的粉丝或者关注时就会复杂一些了，需要用到子查询或者连表

1)、用内连接查找所有互粉（可以根据自身需求在后面把查询范围补上，如用户1&用户2的关注/粉丝列表）：

select a.* from tb_vip_follow as a inner join tb_vip_follow as b on a.followed_vip_id = b.vip_id and a.vip_id = b.followed_vip_id

2)、用子查询查找用户1和用户2的共同关注

select followed_vip_id from tb_vip_follow where followed_vip_id in (select followed_vip_id from tb_vip_follow where vip_id = 1) and vip_id = 2

3)、用子查询查找用户2和用户3的共同粉丝

select vip_id from tb_vip_follow where vip_id in (select vip_id from tb_vip_follow where followed_vip_id = 3) and followed_vip_id = 2

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

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

3.数据库瓶颈，并发受限。

基于mysql存在的缺点，使用redis的Hash数据类型配合使用。

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

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

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

优点
1.查询处理速度快。

缺点
1.消耗服务器内存和CPU。最好使用一台单独的服务器来运行 Redis
2.数据查询，处理不如关系型数据库灵活。
3.开发步骤复杂，学习成本高。

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

关注与粉丝表结构设计及查询

网址：MySQL关于用户关注粉丝表的设计方案 http://mxgxt.com/news/view/1043048

相关内容

mysql关注表设计 包含是否互关
mysql怎么建表关系图,数据库表关系怎么建
如何查看mysql数据库表之间的关系
mysql数据库表关系图怎么生成
关于并发的一些设计
mysql怎么创建数据库关系图
如何修复MySQL错误1100？
搭建用户画像的八个模块建设
【MySQL】设置好友关系（关注、粉丝、互关）的数据库设计
Redis在实现网站粉丝关注与展示功能中的应用

随便看看