先说核心判断：触发器必须建在关注关系表上，而不是用户表上。因为增删关注关系时，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变复杂，但对读多写少的社交计数场景，仍是目前最直接可控的方案。关键不是“能不能用”，而是“在哪用、怎么兜底、怎么验证”。
