应设计独立中间表video_favorites，含user_id、video_id联合唯一索引及双向普通索引，并启用级联删除；收藏/取消用INSERT IGNORE+事务判断行数实现原子操作；用户收藏状态通过一次性查询+array_flip后isset()高效判断；收藏数须Redis缓存并双写更新。
用户收藏关系表怎么设计才合理
视频收藏本质是多对多关系：一个用户可以收藏多个视频，一个视频也能被多个用户收藏。直接在 videos 表加 collected_user_ids 字段（如 JSON 数组）看似简单，但会破坏范式、无法索引、难以统计和查询。
必须建独立中间表：
CREATE TABLE video_favorites (
id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
user_id INT UNSIGNED NOT NULL,
video_id INT UNSIGNED NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_user_video (user_id, video_id),
KEY idx_video_user (video_id, user_id),
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
FOREIGN KEY (video_id) REFERENCES videos(id) ON DELETE CASCADE
);
-
UNIQUE KEY uk_user_video防止重复收藏，也是判断是否已收藏的最快依据 -
KEY idx_video_user支持按视频查所有收藏者（比如“谁收藏了这个视频”） - 用
ON DELETE CASCADE保证视频或用户删除时自动清理收藏记录
收藏/取消收藏接口如何避免并发重复提交
用户快速双击“收藏”按钮，可能触发两次请求，导致插入重复记录（虽然唯一索引会报错），但错误处理不优雅，还可能影响前端状态同步。
推荐用原子操作 + 前端防抖结合：
-
后端用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO，但更稳妥的是先SELECT再INSERT/DELETE，配合事务 - 实际推荐用 MySQL 的
INSERT IGNORE+ 返回影响行数判断 - PHP 示例中不要用
if (already_exists) { delete } else { insert }这种两步查询，有竞态风险
$pdo = new PDO(...);
$pdo->beginTransaction();
$stmt = $pdo->prepare("INSERT IGNORE INTO video_favorites (user_id, video_id) VALUES (?, ?)");
$stmt->execute([$user_id, $video_id]);
if ($stmt->rowCount() === 1) {
// 新增成功 → 是收藏操作
$result = ['action' => 'collected', 'count' => getFavoriteCount($video_id)];
} elseif ($stmt->rowCount() === 0) {
// 无新增 → 尝试删除
$del = $pdo->prepare("DELETE FROM video_favorites WHERE user_id = ? AND video_id = ?");
$del->execute([$user_id, $video_id]);
if ($del->rowCount() === 1) {
$result = ['action' => 'canceled', 'count' => getFavoriteCount($video_id)];
} else {
throw new Exception('操作失败：未收藏也无法取消');
}
}
$pdo->commit();
如何高效查询“用户是否收藏了某视频”
首页列表、详情页都需要实时显示“已收藏”状态，不能每个视频都查一次数据库。
最常用且低开销的方式是：一次性查出该用户所有收藏的 video_id，存为 PHP 关联数组键（array_flip()），再用 isset() 判断：
$favoriteVideoIds = array_flip(
$pdo->query("SELECT video_id FROM video_favorites WHERE user_id = $user_id")->fetchAll(PDO::FETCH_COLUMN)
);
// 渲染视频列表时
foreach ($videos as $v) {
$isFavorited = isset($favoriteVideoIds[$v['id']
]);
echo '';
}
- 比循环中对每个视频执行
SELECT COUNT(*)快一个数量级 - 如果用户收藏量极大（>5k），可改用 Redis 的
SET存储user:123:favorites，用SISMEMBER查询 - 注意：不能用
IN子查询把收藏 ID 拼进视频主查询——ID 太多会超 SQL 长度限制，也难优化
收藏数缓存为什么不能只靠数据库 COUNT(*)
视频详情页显示“已有 24832 人收藏”，每次访问都执行 SELECT COUNT(*) FROM video_favorites WHERE video_id = ?，在高并发下会成为性能瓶颈，尤其当收藏表超百万行时。
必须引入缓存层，但要注意一致性：
- 收藏/取消时，除了操作
video_favorites表，**必须同步更新缓存**（如 Redis 的video:123:favorite_count） - 缓存设带过期时间（如 3600 秒），防止极端情况下缓存与 DB 不一致太久
- 避免用“读时回源 + 加锁更新”这种复杂方案；简单场景下，写操作双写（DB + Cache）足够可靠
- Redis 示例：
INCRBY video:123:favorite_count 1/DECRBY video:123:favorite_count 1
缓存失效不是最难的，难的是写操作漏掉缓存更新——这是线上最常导致“收藏数不准”的原因。
