怎样用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 变复杂，但对读多写少的社交计数场景，仍是目前最直接可控的方案。关键不是“能不能用”，而是“在哪用、怎么兜底、怎么验证”。