点赞与收藏必须分表存储，使用post_likes和post_favorites关联表；查“是否已操作”应优先用exists子查询；点赞/取消需依赖唯一索引与insert…on duplicate key update实现原子性；计数宜用redis缓存+异步对齐，避免并发更新错误。
点赞与收藏必须分表，不能塞进主内容表
把 like_count 或 fav_count 字段直接加到文章表（比如 posts）里，短期看着省事，长期必踩坑：并发更新导致计数不准、无法追溯谁点的赞、没法做「已点赞」状态判断。真实项目里，点赞和收藏是独立行为，必须用关联表记录用户动作。
推荐结构：
-
post_likes表：字段含user_id、post_id、created_at，联合唯一索引(user_id, post_id) -
post_favorites表：结构同上，分离存储更利于权限控制和后续扩展（比如收藏夹分类）
查「是否已点赞」要用 EXISTS 而不是 LEFT JOIN
前端渲染按钮时，需要知道当前用户对某条内容是否已操作。用 LEFT JOIN 加 IS NOT NULL 判断，看似直观，但在数据量大、用户频繁刷列表时，JOIN 会拖慢主查询。更高效的方式是子查询 + EXISTS：
select p.id, p.title, EXISTS(SELECT 1 FROM post_likes l WHERE l.post_id = p.id AND l.user_id = 123) AS is_liked, EXISTS(SELECT 1 FROM post_favorites f WHERE f.post_id = p.id AND f.user_id = 123) AS is_favored FROM posts p WHERE p.status = 'published';只要命中索引，EXISTS 在找到第一条匹配就终止，比 JOIN 扫全量更轻量。注意确保 post_likes(user_id, post_id) 和 post_favorites(user_id, post_id) 都建了联合索引。
点赞/取消点赞要靠 INSERT … ON DUPLICATE KEY UPDATE 或 REPLACE INTO
用户点一次按钮，可能赞，也可能取消赞——本质是「有则删、无则增」的原子操作。mysql 没有原生的 UPSERT 布尔翻转语法，得靠唯一索引配合：
- 先确保
post_likes表有UNIQUE KEY (user_id, post_id) - 点赞：用
INSERT INTO post_likes (user_id, post_id) VALUES (123, 456) ON DUPLICATE KEY UPDATE created_at = NOW(); - 取消赞：用
delete FROM post_likes WHERE user_id = 123 AND post_id = 456;
别用 REPLACE INTO，它底层是 DELETE + INSERT，在有外键或触发器时行为不可控；也别先 SELECT 再决定删或插，存在竞态风险。
计数缓存不能只靠 MySQL 自增字段
实时查 SELECT COUNT(*) FROM post_likes WHERE post_id = 456 在高并发场景下会成瓶颈。但也不能简单在 posts 表里加个 like_count 字段然后每次 UPDATE posts SET like_count = like_count + 1 —— 这种写法在并发点赞时大概率出错（读-改-写非原子）。
稳妥做法是：
- 业务层用
INSERT ... ON DUPLICATE KEY UPDATE完成动作后，再异步更新计数（如通过消息队列） - 或使用带条件的原子更新：
UPDATE posts SET like_count = like_count + 1 WHERE id = 456 AND (SELECT COUNT(*) FROM post_likes WHERE post_id = 456 AND user_id = 123) = 0;，但这语句可读性差、性能不稳，仅作保底 - 更常见的是：前端展示用缓存（Redis 的
HINCRBY），后台定时任务每天对齐一次 MySQL 全量统计
真正难的不是怎么存，而是怎么让「用户看到的数字」和「他刚点下的那一刻的状态」保持一致——这个一致性边界，得在接口设计时就想清楚，不能全丢给数据库扛。