点赞与收藏必须分表，不能塞进主内容表
把
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 全量统计
真正难的不是怎么存，而是怎么让「用户看到的数字」和「他刚点下的那一刻的状态」保持一致——这个一致性边界，得在接口设计时就想清楚，不能全丢给数据库扛。
