MySQL關於用戶關注粉絲表的設計方案

1、數據結構分析
用戶關注粉絲是一個多對多的數據模型，分析對象的數據特徵，咱們給每一個用戶設計一個關注者屬性和粉絲屬性，用於存儲用戶的關注者id和粉絲id，如用戶1：
$arr1 = [
'follow' => '[2,3,4],
'fans' => [4,5,6],
]

2、用戶邏輯關係梳理
在用戶關注粉絲模型中，有兩種常見場景：
1.查看本身的粉絲或者關注列表：
這種狀況下最多會出現三種關係：
其中1表示僅爲本人所關注的人，2表示僅爲本人的粉絲，3表示互粉
111

2.查看別人的粉絲或者關注列表：
此時是以別人的粉絲或關注者與本身的關係進行斷定：

其中find表示別人的粉絲或關注列表，在這裏統稱爲other，1表示other是本人所關注的，2表示other與本人互粉，3表示other是本人的粉絲，4表示和本人沒有任何關係
222

3、數據庫設計
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=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='會員關注關係表';

333

用戶每關注一我的，都會在表中添加一條數據，eg：
用戶1關注了用戶2，用戶3；
用戶2關注了用戶1，用戶3和用戶4；

用戶1有粉絲用戶2；
用戶2有粉絲用戶1；
用戶3有粉絲用戶1，用戶2；
用戶4有粉絲用戶2；

用戶1和用戶2互粉。

4、應用
這裏爲了省事，就沒有考慮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數據類型配合使用。

5、使用redis的Hash數據類型
Redis hash是一個string類型的field和value的映射表。
Redis 中每一個 hash 能夠存儲 232 - 1 鍵值對（40多億）。

每一個用戶分一張hash表，表名爲用戶id（可加前綴或後綴）

用戶每關注一我的，便在hash表中添加一條數據
444

555

優勢
1.查詢處理速度快。

缺點
1.消耗服務器內存和CPU。最好使用一臺單獨的服務器來運行 Redis
2.數據查詢，處理不如關係型數據庫靈活。
3.開發步驟複雜，學習成本高。

參考文章
MySQL關於用戶關注粉絲表設計方案的思考
https://blog.csdn.net/sinat_21026543/article/details/80078993?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1