我有一个表用于存储用户对帖子的反馈,如下所示
Table: user_feedback. Feedback_id is PRI AI
Feedback_id Post_id User_id
1 1 1
2 2 1
3 1 3
4 1 4
5 5 1
在我的posts表中,我目前有这样的内容:
Table: posts
Post_id Likes
1 3
2 1
5 1
每次帖子被点赞时,我就增加点赞计数器,然后运行
获取帖子的点赞数SELECT likes FROM posts WHERE post_id = 1;
但是,这值得麻烦(例如,存储反馈和MySQL不知何故不能增加计数器)维护它,它甚至更快吗?
:
SELECT COUNT(feedback_id) FROM user_feedback WHERE post_id = 1;
SELECT COUNT响应时间将随着数据的增长而降低。我会选择第一个选项。然而,使用关系数据库可能是多余的,也许你应该看看在后台持久化到磁盘的内存缓存,以及类似的东西(redis, guava, memcache等)。
同样,如果这个数字不是"关键任务",你可以忍受更新失败。
这是不正常的,但我们看到的情况更糟。这是常见的做法,但容易出错。但是,如果向反馈的插入可以包装在事务中:反馈插入发生和,则对Likes
的更新都成功,否则事务将回滚。
使用这个Likes
列可以大大提高性能。它是一个瘦的数据类型大小,如果您将它与post_id结合在covered index
(复合)中,那么在查询post_id
, Likes
时,它完全可以在索引页中使用,而无需db引擎在数据页之后(更不用说不需要连接)。昨晚看到一个拥有数千万行数据的人得到了简洁的输出。