收藏功能必须用独立关联表user_favorites实现多对多关系，结构含user_id、item_id、created_at及联合唯一索引ux_user_item；查询状态用EXISTS子查询；增删操作依赖唯一索引原子执行。
收藏功能必须用单独的关系表，不能加字段到原表
直接在用户表或内容表里加 is_favorited 字段是错的——一个用户可以收藏多条内容，一条内容也能被多个用户收藏，这是典型的多对多关系。强行塞字段会导致数据冗余、更新异常，甚至无法查询“某用户收藏了哪些内容”。必须建一张独立的关联表，比如 user_favorites。
推荐结构：user_id（INT/unsigned，外键指向用户表）item_id（INT/unsigned，外键指向目标内容表，如 article 或 video）created_at（DATETIME，默认 CURRENT_TIMESTAMP）
联合唯一索引：UNIQUE KEY `ux_user_item` (`user_id`, `item_id`)
这个索引既防止重复收藏，又让“查某用户所有收藏”和“查某内容是否被某用户收藏”两个高频操作走索引，避免全表扫描。
判断是否已收藏：用 EXISTS 比 LEFT JOIN 更快
前端列表页需要显示“已收藏/未收藏”状态，常见错误是先查出所有内容，再对每条内容执行一次 SELECT 1 FROM user_favorites WHERE user_id = ? AND item_id = ? ——N+1 查询，扛不住。
正确做法是在主查询中用 EXISTS 关联判断：
SELECT a.id, a.title,
EXISTS(SELECT 1 FROM user_favorites f
WHERE f.user_id = 123 AND f.item_id = a.id) AS is_favorited
FROM article a
WHERE a.status = 'published'
ORDER BY a.created_at DESC
LIMIT 20;关键点：
- 不要用 LEFT JOIN user_favorites ON ... WHERE f.user_id IS NULL/NOT NULL，NULL 判断可能漏掉没匹配的行
- EXISTS 在命中第一条记录后就短路返回，比 COUNT(*) > 0 更轻量
- 确保 user_favorites 表上有 (user_id, item_id) 联合索引，否则 EXISTS 子查询会变慢
收藏/取消收藏必须用 INSERT … ON DUPLICATE KEY UPDATE 或 REPLACE
前端点击“收藏”按钮时，不能先 SELECT 再决定 INSERT 或 DELETE —— 并发下可能重复插入或误删。正确方式是依赖唯一索引做原子操作。
收藏（无论之前是否存在）：
INSERT INTO user_favorites (user_id, item_id) VALUES (123, 456) ON DUPLICATE KEY UPDATE created_at = CURRENT_TIMESTAMP;
取消收藏（安全删除，不报错）：
DELETE FROM user_favorites WHERE user_id = 123 AND item_id = 456;
注意：
- 不要用 REPLACE INTO，它本质是 DELETE + INSERT，在有自增主键时会浪费 ID，且触发器行为不同
- ON DUPLICATE KEY UPDATE 要求表有 PRIMARY KEY 或 UNIQUE KEY，所以前面建的 ux_user_item 索引必不可少
- 如果业务需要记录“收藏过几次”，可把 UPDATE 改成 counter = counter + 1，但一般不需要
分页查收藏列表时，别忘了给 item_id 加索引
用户进入“我的收藏”页，要按时间倒序分页查 user_favorites 表，SQL 类似：
SELECT a.* FROM user_favorites f JOIN article a ON f.item_id = a.id WHERE f.user_id = 123 AND a.status = 'published' ORDER BY f.created_at DESC LIMIT 20 OFFSET 40;
这里容易忽略的是：虽然 user_favorites 有 (user_id, item_id) 索引，但 ORDER BY f.created_at 是另一列。如果只靠那个联合索引，MySQL 可能无法高效排序，导致 Using filesort。
解决方案：
- 添加复合索引：INDEX `ix_user_created` (`user_id`, `created_at` DESC)
- 同时确保 article.id 有主键（自然满足），JOIN 才能走索引驱动
- 如果内容表（如 article）本身数据量大，且 status 过滤条件选择性低，考虑把 status 也加入索引，例如 (user_id, status, created_at)，但需权衡写入开销
最常被跳过的其实是索引覆盖问题：查收藏列表时，如果只要 item_id 和 created_at，其实连 article 表都不用 JOIN，直接查 user_favorites 更快——别默认以为“列表页必须带标题和摘要”。
