如何设计添加好友功能的数据库表结构及关联关系？

设计添加好友的数据库需要综合考虑数据结构、性能、安全性和扩展性，以确保系统高效稳定运行,以下是关键步骤和设计要点：

需求分析

在开始设计前，需明确业务需求，是否支持双向好友（如微信）或单向关注（如微博）？是否需要好友分组、备注功能？是否限制好友数量？这些需求将直接影响表结构设计，需考虑用户规模，预估数据量,避免后期扩展时出现性能瓶颈。

核心表结构设计

用户表（users）

存储用户基本信息,是好友关系的基础。

• 字段设计：user_id（主键，唯一标识）、username、password_hash、email、phone、created_at、updated_at等。
• 索引：user_id设为主键索引，username和email可设为唯一索引,加速查询。

好友关系表（friendships）

核心表,记录用户间的好友关系。

• 字段设计：id（主键）、user_id（发起方好友请求）、friend_id（接收方好友请求）、status（关系状态，如pending、accepted、blocked）、created_at、updated_at。
• 索引：user_id和friend_id需联合索引，加速查询双向关系，status字段可单独索引,优化按状态筛选的查询。

好友备注表（friend_notes）

可选表,用于存储用户对好友的备注信息。

• 字段设计：id、user_id、friend_id、note、created_at、updated_at。
• 索引：user_id和friend_id联合索引,确保唯一性。

好友分组表（friend_groups）

可选表,支持好友分组功能。

• 字段设计：id、user_id、group_name、created_at、updated_at。
• 索引：user_id和group_name联合索引,避免重名分组。

关系状态管理

好友关系需明确状态流转逻辑：

• pending：发送好友请求后，默认状态,等待对方确认。
• accepted：接收方同意后，状态变为“已添加好友”。
• blocked：任一方拉黑后，状态为“已屏蔽”,不再显示好友关系。
• rejected：接收方拒绝后,可标记为已拒绝或直接删除记录。

数据一致性与完整性

• 外键约束：friendships表的user_id和friend_id需关联users表的user_id,确保数据有效性。
• 事务处理：添加好友或修改状态时，使用事务保证操作原子性,避免部分失败导致数据不一致。
• 唯一约束：避免重复添加好友，可在friendships表上设置(user_id, friend_id)联合唯一约束。

性能优化

• 分表分库：若用户量巨大，可按user_id哈希或范围分表,减轻单表压力。
• 缓存策略：使用Redis缓存好友列表，减少数据库查询，以user_id为key，好友ID列表为value,设置过期时间。
• 读写分离：读操作较多时,可配置从库分担查询压力。

安全设计

• 权限控制：确保用户只能操作自己的好友关系,如防止A查看或修改B的好友列表。
• 输入验证：对user_id和friend_id进行合法性校验,防止SQL注入或非法访问。
• 敏感操作日志：记录好友添加、删除、拉黑等操作,便于审计和问题排查。

扩展性考虑

• 字段预留：在friendships表中预留扩展字段（如添加来源、备注）,避免后期频繁修改表结构。
• 支持多端同步：若涉及多端登录，需设计消息队列或事件驱动机制,实时同步好友关系变更。

API接口设计

基于数据库设计,可提供以下核心接口：

• 发送好友请求：POST /api/friendships,参数为friend_id。
• 接受/拒绝请求：PUT /api/friendships/{id}/status,参数为status。
• 获取好友列表：GET /api/friendships,支持分页和状态筛选。
• 删除好友：DELETE /api/friendships/{friend_id}。

FAQs

Q1: 如何高效查询两个用户是否为好友？
A1: 可在friendships表中建立(user_id, friend_id, status)的联合索引，通过查询SELECT 1 FROM friendships WHERE (user_id = ? AND friend_id = ?) OR (user_id = ? AND friend_id = ?) AND status = 'accepted'快速判断双向好友关系，若使用缓存，可先从Redis中获取好友列表,再检查是否存在。

Q2: 如何处理好友请求的超时？
A2: 可设计定时任务（如每日扫描），将超过一定时间（如7天）仍为pending状态的请求标记为expired或自动删除，也可在前端设置请求过期提醒,引导用户及时处理。