直接用数据库自增字段实现点赞计数虽强一致但高并发下性能差；UPDATE likes=likes+1存在丢失更新、行锁争用、无法去重三大问题；推荐Redis缓存+MySQL落库+用户去重的三层方案。
直接用数据库自增字段实现点赞计数，是最简单且能保证强一致性的方案；但高并发下容易成为
性能瓶颈
，需配合缓存与异步落库来平衡准确性和响应速度。
为什么不能只靠
这条 SQL 看似简洁，但在真实场景中会暴露三个关键问题：
并发写入时可能丢失更新（两个请求同时读到
，各自加 1 后都写回
）
频繁更新单行记录会导致 InnoDB 行锁争用，QPS 上千后明显变慢
无法区分“同一用户重复点击”，即缺少去重逻辑
推荐的三层结构：Redis 缓存 + MySQL 落库 + 用户维度去重
核心思路是：先用 Redis 记录用户对视频的点赞状态和临时计数，再异步批量同步到 MySQL。这样既防刷、又抗压。
关键实现点：
立即学习
“
PHP免费学习笔记（深入）
”；
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
用
或
标记用户是否已点过赞（
）
点赞成功后，向有序集合
插入用户 ID（score 可设为时间戳），用于后续查谁点了赞
使用
增加计数器
，这是
前端
展示用的实时值
每 5 分钟用脚本扫描 Redis 中的计数器，用
读取并执行
批量落库
MySQL 表结构必须支持幂等更新和唯一约束
如果跳过 Redis 直接操作数据库，至少要满足两点：防止重复计数、避免锁表。示例如下：
这个写法依赖
和
子查询，能规避大部分并发冲突，但仍有小概率因执行顺序导致计数偏差——所以生产环境仍建议走 Redis+异步。
前端展示时别直接读 Redis 计数器
是高频变更数据，但 Redis 没有事务，万一异步脚本崩溃，它可能比 MySQL 多出几百个赞。稳妥做法是：
日常展示优先读 Redis（快）
用户进入详情页时，额外发一次
（准）
若两者差值超过阈值（比如 > 50），就用 DB 值覆盖 Redis 并触发补偿任务
这个细节很多人忽略，结果上线后发现“点赞数一会儿多一会儿少”，其实是缓存和 DB 不一致没兜住。
UPDATE ... SET likes = likes + 1likes=100101SETNXRedis::set($key, $value, ['nx', 'ex' => 3600])video:like:uid:123:vid:456video:likes:456INCRvideo:likes:count:456GETUPDATE video SET likes = likes + ? WHERE id = ?CREATE TABLE video_likes (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
video_id INT NOT NULL,
user_id INT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_video_user (video_id, user_id)
);
-- 原子性插入，失败则说明已点过
INSERT INTO video_likes (video_id, user_id) VALUES (456, 123)
ON DUPLICATE KEY UPDATE id = id;
-- 再单独更新计数（注意：这里不是 SELECT + UPDATE）
UPDATE video SET likes = likes + 1 WHERE id = 456 AND NOT EXISTS (
SELECT 1 FROM video_likes WHERE video_id = 456 AND user_id = 123
);
UNIQUE KEYNOT EXISTSvideo:likes:count:456SELECT likes FROM video WHERE id = 456