怎样用SQL触发器自动维护社交应用的粉丝数和关注数
触发器必须建在关注关系表（如follows）上，而非用户表；因为增删关注时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 变复杂，但对读多写少的社交计数场景，仍是目前最直接可控的方案。关键不是“能不能用”，而是“在哪用、怎么兜底、怎么验证”。
