如何优化内容关注者计数查询性能 避免全表扫描拖慢SQL执行速度

基础优化（成本最低，优先做） #

你担心的全表扫描问题完全可以通过加索引解决，不需要改动业务逻辑：

• 给关联表content-followers的content_id字段创建普通索引，执行SQL：
  CREATE INDEX idx_cf_content_id ON content_followers(content_id);
• 加完索引后，查询单条内容的关注数的语句SELECT COUNT(*) FROM content_followers WHERE content_id = [你的内容ID]会直接走索引统计，不会扫描全表，性能足够支撑绝大多数普通流量的场景。

进阶优化（流量大时可选） #

如果加完索引后还有性能瓶颈，可以用你提到的冗余存储计数的方案，分两种实现：

实时更新方案（优先选，计数准确） #

• 第一步在contents表新增一个follower_count整数类型字段，默认值设为0
• 后续用户点击关注/取消关注时，除了新增/删除content-followers表的对应记录，同时更新contents表的对应字段：
  关注时执行 UPDATE contents SET follower_count = follower_count + 1 WHERE id = [内容ID]
  取消关注时执行 UPDATE contents SET follower_count = follower_count - 1 WHERE id = [内容ID]
• 后续内容页展示关注数直接读取contents表的follower_count字段即可，不需要关联查询，性能最优。

定时统计方案（适合对计数准确性要求不高的场景） #

• 同样先在contents表加follower_count字段
• 写一个后台定时脚本，按你能接受的延迟间隔（比如30分钟/1小时）批量统计所有内容的关注数更新到contents表，统计参考SQL：

UPDATE contents c
LEFT JOIN (
  SELECT content_id, COUNT(*) AS cnt FROM content_followers GROUP BY content_id
) cf ON c.id = cf.content_id
SET c.follower_count = COALESCE(cf.cnt, 0)

• 这个方案不需要改动现有关注/取消的业务逻辑，但计数会有延迟，适合允许计数存在短时间误差的场景。

选型建议 #

优先做基础的索引优化即可，绝大多数场景下够用。如果流量确实很高，再选择实时更新的冗余字段方案，定时统计的方案是优先级最低的选项。

内容的提问来源于stack exchange，提问作者Isaac Newton Aranas