点赞功能数据库设计时，如何高效存储与查询用户点赞状态？

点赞功能的数据库设计是社交平台、内容管理系统等应用中的核心环节，合理的数据库结构不仅能提升系统性能，还能支持复杂的业务逻辑，以下从数据模型设计、核心表结构、索引优化、扩展性考量及安全性等方面，详细拆解点赞功能的数据库实现方案。

数据模型设计基础

点赞功能的核心是记录用户对特定内容（如文章、视频、评论）的点赞行为，本质上是一种“多对多”关系——一个用户可以点赞多个内容，一个内容也可以被多个用户点赞，在关系型数据库中，这种关系通常通过中间表（关联表）来实现，即单独设计一个“点赞记录表”，用于存储用户ID与内容ID的对应关系，同时附加时间戳等元数据，这种设计既避免了数据冗余，又能高效支持查询与统计。

核心表结构设计

点赞记录表（如user_likes）是核心表，需包含以下关键字段：

• id：主键，通常使用自增ID或UUID，确保每条记录唯一。
• user_id：外键关联用户表，记录点赞发起者，需建立索引以加速查询。
• target_type类型字段（如1代表文章、2代表视频），用于区分点赞对象，支持多业务场景复用。
• target_idID，关联被点赞的具体内容（如文章ID或视频ID）。
• created_at：点赞时间，默认值为当前时间，用于排序或统计近期活跃度。
• status：状态字段（如0正常、1取消点赞），支持软删除，避免物理删除导致数据断层。

MySQL建表示例：

CREATE TABLE user_likes (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    target_type TINYINT NOT NULL COMMENT '1:文章 2:视频',
    target_id BIGINT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    status TINYINT DEFAULT 0 COMMENT '0:点赞 1:取消',
    INDEX idx_user_target (user_id, target_type, target_id),
    INDEX idx_target_user (target_type, target_id, user_id)
) ENGINE=InnoDB;

索引优化与查询效率

索引是提升查询性能的关键,针对点赞功能，需设计复合索引：

1. 用户维度索引：(user_id, target_type, target_id)，快速查询用户点赞过的内容列表，避免全表扫描，维度索引**：(target_type, target_id, user_id)，高效统计内容的点赞数或判断用户是否已点赞，

   -- 查询文章ID为100的点赞数
   SELECT COUNT(*) FROM user_likes WHERE target_type=1 AND target_id=100 AND status=0;
   -- 检查用户ID为10是否点赞了文章100
   SELECT id FROM user_likes WHERE user_id=10 AND target_type=1 AND target_id=100 AND status=0;

   若业务涉及高频排序（如“最新点赞”），可为created_at添加单独索引；若数据量极大，可考虑分库分表，按user_id或target_id哈希分片，减少单表压力。

扩展性考量

随着业务增长,点赞功能可能面临更高并发与复杂需求，需提前设计扩展方案：

• 缓存层引入：使用Redis缓存点赞数和用户点赞状态，减少数据库直接访问，用target_type:target_id作为键存储点赞数，用user_id:target_type:target_id作为键存储用户点赞状态，设置过期时间与数据库异步更新。
• 读写分离：将统计查询（如获取点赞数）路由到从库，降低主库压力。
• 数据归档：对历史点赞数据（如超过1年的记录）进行归档，迁移至冷存储表，保证主表查询效率。

安全性与数据一致性

• 防重复点赞：通过数据库唯一索引（如UNIQUE KEY idx_user_target (user_id, target_type, target_id)）确保同一用户对同一内容只能有一条点赞记录，避免重复数据。
• 事务处理：在涉及点赞数更新的场景（如用户点赞时，内容表点赞数+1），需使用数据库事务保证数据一致性，

  BEGIN;
  INSERT INTO user_likes (user_id, target_type, target_id) VALUES (10, 1, 100) ON DUPLICATE KEY UPDATE status=0;
  UPDATE posts SET like_count = like_count + 1 WHERE id = 100;
  COMMIT;

• 权限校验：在应用层添加用户登录态校验，防止未登录用户恶意刷点赞。

---

相关问答FAQs

Q1：如何高效实现“获取点赞用户列表”功能？
A：可通过分页查询点赞记录表，按created_at降序排序，并结合LIMIT offset, size实现分页。SELECT user_id FROM user_likes WHERE target_type=1 AND target_id=100 AND status=0 ORDER BY created_at DESC LIMIT 10, 10，若需展示用户详细信息，可关联用户表（JOIN），但需注意控制查询数据量，避免大表关联性能问题，可通过缓存存储热门内容的点赞用户列表，减少数据库访问。

Q2：点赞数实时更新与数据库性能如何平衡？
A：可采用“缓存+异步更新”策略：用户点赞时，先更新Redis中的点赞数（如INCR命令），并记录操作到消息队列（如Kafka）；后台消费者消费消息后，批量更新数据库（如每秒合并100次操作写入数据库），这样既保证了前端点赞数的实时性，又减少了数据库直接写入压力，设置缓存过期时间（如5分钟），在缓存失效时从数据库重新加载，确保数据最终一致性。