大型社交项目中likes和follows表必须物理分离、用联合主键去重、按查询路径建索引，且不可依赖实时COUNT(*)查总数；否则单表过亿将导致主库CPU飙升、P99延迟翻倍。
直接上结论：大型社交项目里，likes 和 follows 表必须物理分离、联合主键去重、索引按查询路径建，且不能依赖实时 COUNT(*) 查总数——否则单表过亿行后，主库 CPU 会持续飙高，接口 P99 延迟翻倍。
为什么不能把 is_liked 加到 posts 表里
看似省事，实则埋雷。每次用户点赞都要 UPDATE posts SET like_count = like_count + 1 WHERE id = ?，高并发下会引发行锁争抢；更致命的是无法回溯“谁点过赞”，做风控、召回、导出都卡死。另外，一个系统里通常有 post/comment/video/user 多种被点赞对象，硬塞进 posts 表会导致字段语义混乱、迁移困难。
-
is_liked是用户视角的状态，like_count是内容视角的聚合值，二者维度不同，强行耦合违反单一职责 - 如果某天要支持“点赞后 24 小时内可撤回但计数不减”，这种业务逻辑在冗余字段里根本没法扩展
- MySQL 8.0+ 虽支持原子自增，但
UPDATE ... SET x = x + 1在主从复制中仍可能因 binlog format（STATEMENT vs ROW）产生延迟抖动
likes 表怎么建才扛住日均千万级写入
核心就三点：用联合主键替代唯一索引、target_type 存字符串别用外键、(target_type, target_id) 必须有联合索引。
- 建表语句示例：
CREATE TABLE likes ( user_id BIGINT NOT NULL, target_type VARCHAR(20) NOT NULL COMMENT 'post|comment|video', target_id BIGINT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (user_id, target_type, target_id) );
-
PRIMARY KEY (user_id, target_type, target_id)比UNIQUE KEY更高效：InnoDB 主键即聚簇索引，写入时 B+ 树分裂更可控，且避免额外二级索引维护开销 -
target_type不用外键或 tinyint 枚举：跨类型关联会锁死迁移节奏；比如新增live_stream类型，不用改外键约束，只改应用层判断即可 - 必须加索引：
CREATE INDEX idx_target ON likes (target_type, target_id)——这是查“某条视频被赞多少次”的命脉，没它COUNT(*)就是全表扫描
关注关系表 follows 的特殊优化点
关注比点赞多一层“反向查询”需求：查“谁关注了我”比“我关注了谁”更重，尤其在首页 Feed 流和通知系统里。
- 基础结构类似 likes，但主键建议设为
(follower_id, followee_id)，再额外建一个INDEX idx_followee ON follows (followee_id, follower_id) - 不要用
ON DELETE CASCADE：大 V 被取关时，级联删除可能触发长事务，拖慢整个实例；改为应用层分批删除（每次 500 条 +SLEEP(0.01)）更稳妥 - 如果要做“互相关注”判定，别用两次
EXISTS，直接SELECT 1 FROM follows f1 JOIN follows f2 ON f1.follower_id = f2.followee_id AND f1.followee_id = f2.follower_id WHERE f1.follower_id = ? AND f1.followee_id = ? - 高频场景如“关注按钮状态”，用
SELECT 1 FROM follows WHERE follower_id = ? AND followee_id = ? LIMIT 1，返回非空即已关注，比查 COUNT 快一个数量级
缓存 like_count/follow_count 的坑在哪
缓存本身不是问题，问题是缓存失效策略。直接在 MySQL 里用触发器更新 posts.like_count 看似自动，但在分库分表或读写分离架构下，触发器只在主库生效，从库延迟会导致计数不一致。
- 推荐方案：写操作走 MySQL 记录明细，读总数时用 Redis 的
INCRBY/DECRBY实时维护，每小时用SELECT COUNT(*)对一次账（对账脚本避开高峰） - 千万别让 Redis 计数和 MySQL 明细完全脱钩——曾有项目因 Redis 故障丢失增量，靠
COUNT(*)全量重建花了 7 小时，期间所有列表页显示“0 点赞” - 如果不用 Redis，至少在应用层做“写后双删”：先删缓存，再写 MySQL，最后再删一次缓存（防写库成功但第一次删缓存失败）
真正难的不是建表，而是当 likes 表突破五亿行后，idx_target 索引的 B+ 树层级变深，COUNT(*) 即使走索引也会变慢。这时候得切分逻辑——比如按 target_type 拆成 post_likes/comment_likes，而不是盲目上分库分表。
