MySQL中高效处理多种类型「关注」功能的方案探讨

一、三张关联表方案的合理性 #

这个方案在特定业务场景下是完全合理的，但也存在明显的局限性，我们来拆解它的优缺点：

优点 #

• 完全贴合数据库范式设计，数据结构清晰无冗余，后续维护时容易理解
• 外键约束能直接保证数据完整性，不会出现“关注一个不存在的用户/车辆/零部件”的无效数据
• 单表查询性能优异：比如统计用户关注的车辆数量，直接查询FollowUserCar表即可，无需额外的类型判断逻辑
• 代码层面的CRUD逻辑直观：每个关注类型对应独立的表和处理模块，新人接手时容易上手

缺点 #

• 扩展性差：未来新增可关注对象（比如汽车子型号）时，必须新增对应的关联表，同时后端代码也要新增实体类、DAO层逻辑，维护成本会随着类型增多线性上升
• 跨类型查询繁琐：如果要查询某个用户所有关注的对象（不管类型），需要联合多张关联表查询，SQL语句会变得复杂且不易维护

二、减少表数量的替代方案：单表多态关联 #

如果想简化表结构、提升扩展性，最常用的方案是单表多态关联，只需要创建一张统一的Follow表即可，结构示例如下：

CREATE TABLE Follow (
    id INT PRIMARY KEY AUTO_INCREMENT,
    follower_id INT NOT NULL, -- 关联关注者的User表ID
    followable_type VARCHAR(50) NOT NULL, -- 被关注对象的类型标识，比如'user'、'car'、'car_part'
    followable_id INT NOT NULL, -- 被关注对象的ID
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    UNIQUE KEY unique_follow_relation (follower_id, followable_type, followable_id) -- 避免重复关注同一对象
);

这个方案的优缺点： #

优点

• 扩展性极强：新增可关注类型时，只需要在followable_type中新增枚举值，无需修改表结构，代码层面也可以通过抽象逻辑统一处理不同类型的关注操作
• 跨类型查询简单：查询用户所有关注对象时，只需查询这一张表，再根据followable_type关联对应的主表即可
• 表数量少，整体数据结构更简洁，减少数据库维护的复杂度

缺点

• 失去数据库层面的外键约束：无法直接通过外键保证followable_id对应的对象存在，需要在应用层做额外校验（比如关注前先检查目标对象是否存在）
• 单表数据量增长更快：所有类型的关注关系都存在这一张表，数据量较大时可能需要考虑分表、索引优化等操作
• 复杂查询性能略逊：比如统计所有关注汽车的用户，需要先筛选followable_type='car'再关联Car表，相比单独的FollowUserCar表，性能会稍差一些（合理建立联合索引可缓解此问题）

三、方案选择建议 #

• 如果你的业务中可关注对象的类型长期稳定（比如短期内不会新增），且对数据完整性、查询性能要求极高，三张关联表的方案更合适
• 如果你的业务未来会频繁新增可关注类型，或者经常需要跨类型查询用户的所有关注对象，单表多态关联的方案更灵活

另外还有一种折中思路：如果部分类型的关注关系需要存储特殊字段（比如关注车辆时记录关注原因），可以以多态关联表为核心，对有特殊需求的类型单独建立扩展表，但这种场景相对少见。

内容的提问来源于stack exchange，提问作者demonoid