如何处理快速增长的mysql表

时间:2013-03-05 08:14:40

标签: mysql sql database performance database-design

我在mysql数据库中有两个表

  1. tbl_comments
  2. tbl_votes
  3. 当用户点击评论下的Like或Dislike按钮时,tbl_votes中会插入一个新行,其中包含comment_id,user_id和vote_type。这意味着如果100个用户每天在100条评论上点击“赞”或“不喜欢”按钮,它将在tbl_votes表中插入10,000行。因此,随着用户数量的增加和投票数量的增加,tbl_votes将迅速增加。并且假设当tbl_votes中有100,000,000行时,它也会影响性能并减慢sql查询的速度。

    我如何处理此解决方案或任何其他解决方案。

4 个答案:

答案 0 :(得分:2)

这是一个非常好的解决方案。 只要您设置了正确的索引,就可以了。(主键索引和帖子ID)

以exxample stackoverflow为例,每个帖子,回复评论都有自己的投票系统,向上或向下,记得投票的人,他们每次投票都有大约2亿条+消息+回复,但仍然会快速响应。

只要索引设置正确,它应该执行得很好。我可能会建议使用bigint作为主键...

答案 1 :(得分:0)

我不担心在可以将索引保留在内存中的机器上使用1 billion行的应用程序性能。

表现取决于:

  1. 这些查询的加入次数
  2. 设置索引的程度
  3. 机器中 RAM 多少
  4. 处理器的速度和数量
  5. 硬盘的类型和主轴速度
  6. 查询中返回的行/数据量的大小

答案 2 :(得分:0)

一些结论:

如果你去rdbms: 如果正确索引以选择注释的总喜欢总和,那么插入表中的行数并不重要,当然你需要保持结果缓存。 快速数据选择的另一种方法 - 保持一些投票数据聚合,因此如果用户投票评论,您的表中将有1个插入/删除,并在另一个表上更新,如

comment_id
rate

所以你要为你需要的任何评论选择费率,聚合表的总行数会少得多。

另一个好方法是使用键值存储。假设您的密钥是comment_id,原始数据的存储值

user_id
vote_type

您选择的依赖或无存储空间,数据可能完全存储在内存中,所有选择/更新操作都可以正常运行

答案 3 :(得分:0)

表的大小不会影响List<ConfigUrlModel>查询,这并不完全正确。 对于大表,我会建议TokuDB。

在这两种情况下,如果您想要ConfigUrlModels某些数据,就会出现问题。 此时,您有两个选择:聚类键或开始考虑不同的架构(水平分片可能是一个好方法):