用SQL触发器自动维护社交应用粉丝数和关注数

先说核心判断：触发器必须建在关注关系表上，而不是用户表上。因为增删关注关系时，users表本身并没有被修改，所以不会触发任何事件。只有盯着follows表的INSERT和DELETE，才能准确更新双方的粉丝数和关注数。

触发器该建在哪个表上才不会漏更新

粉丝数和关注数本质上是双向关系，所以必须在记录关注行为的表（比如follows）上建触发器。如果只在users表上加触发器，INSERT或DELETE操作根本不会触发——因为增删关注关系时，users表本身没被修改。

常见错误是把触发器建在users上，结果数据始终不更新。真正该做的，是盯着follows表的INSERT（新增关注）、DELETE（取消关注），必要时还要处理UPDATE（比如状态字段变更）。

• follows表至少应含follower_id（粉丝ID）、followee_id（被关注者ID）、status（如'active'/'cancelled'）
• 触发器类型选BEFORE INSERT和BEFORE DELETE更稳妥，可以避免并发写入冲突
• 不要用AFTER触发器去更新同一事务中的users表，MySQL 8.0+ 虽然支持，但PostgreSQL会报错

INSERT 和 DELETE 触发器里怎么写更新逻辑

一个关注动作要同时更新两个人的计数：follower_id的「关注数」+1，followee_id的「粉丝数」+1；取消关注则相反。不能只写一条UPDATE，必须两条独立语句，且要用IF EXISTS或INSERT ... ON CONFLICT（PostgreSQL）/ INSERT ... ON DUPLICATE KEY UPDATE（MySQL）兜底，防止用户ID不存在时报错中断事务。

示例（MySQL）：

CREATE TRIGGER follow_insert_update_countsAFTER INSERT ON followsFOR EACH ROWBEGIN  UPDATE users SET following_count = following_count + 1 WHERE id = NEW.follower_id;  UPDATE users SET followers_count = followers_count + 1 WHERE id = NEW.followee_id;END;

• 务必检查users.id有索引，否则每次更新都全表扫描
• 如果follows表有软删除（用status字段），得用INSERT + UPDATE组合触发器，不能只靠DELETE
• 避免在触发器里调用存储过程或外部函数，会显著拖慢写入性能

为什么 COUNT(*) 查询不能替代触发器维护

实时查COUNT(*) FROM follows WHERE followee_id = ?看似简单，但高并发下极易成为瓶颈：每展示一个用户主页就要扫一次关联行，1000个粉丝就是1000行I/O；更糟的是，如果加了分页或排序，COUNT还可能触发临时表和文件排序。

• 粉丝数/关注数属于高频读、低频写字段，符合「以空间换时间」的经典场景
• 触发器维护的数值必须配合应用层校验：比如每天跑一次SELECT u.id, u.followers_count, (SELECT COUNT(*) FROM follows f WHERE f.followee_id = u.id) AS real_count FROM users u WHERE u.followers_count != real_count找出偏差
• 别忘了给users.followers_count和users.following_count加NOT NULL DEFAULT 0，避免空值导致计算异常

事务失败时计数不一致怎么办

触发器在事务内执行，但如果事务回滚，触发器做的UPDATE也会一起回滚——这是默认行为，不用额外处理。真正危险的是「触发器抛异常但没被捕捉」，比如更新时遇到锁超时或唯一键冲突，会导致整个事务失败，反而让业务逻辑卡住。

• MySQL中可在触发器内用DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获错误并设默认值，但不推荐掩盖问题
• 更可靠的做法：把计数更新从触发器移到应用层异步任务（如用Redis队列延迟更新），触发器只负责发消息，降低数据库压力
• 线上环境务必监控information_schema.TRIGGERS的执行失败率，以及users表的followers_count和实际关联数的偏差率

触发器不是银弹，它让写变重、让schema变复杂，但对读多写少的社交计数场景，仍是目前最直接可控的方案。关键不是“能不能用”，而是“在哪用、怎么兜底、怎么验证”。