如何处理快速增长的mysql表答案

【问题标题】：How to deal with a rapidly growing mysql table如何处理快速增长的mysql表
【发布时间】：2013-03-05 08:14:40
【问题描述】：

我在mysql数据库中有两个表

tbl_cmets
tbl_votes

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

我该如何处理这个解决方案或任何其他解决方案。

【问题讨论】：

你有什么引擎？
在一个不再适合 RAM 的大表上，对性能的最大损害往往是 I/O（即硬盘甚至固态驱动器的相对缓慢）。所以，设计你的数据库以最小化 I/O，你应该没问题 - 看看 my answer 给你的其他问题以获得一些想法。

标签： mysql sql database performance database-design

【解决方案1】：

这是一个完美的解决方案。只要您将索引设置正确就可以了。（主键索引和帖子 ID）

以 stackoverflow 为例，每个帖子，回复评论都有自己的投票系统，无论是向上还是向下，都会记住谁投票，他们有大约 2 亿多条消息+回复，每个人都有自己的投票，而且它仍然快速响应。

只要索引设置正确，它应该可以正常运行。我可能会建议使用 bigint 作为主键...

【讨论】：

我同意这一点。如果真的有任何减速，可能是由于数据库设计不佳或其他因素（内存、硬盘速度）。
我对您的短语“（主键索引和帖子 ID）”有点困惑。主键上的索引是什么意思？主键本身不是索引吗？
是的，主键本身就是一个索引，但你必须设置它。您会惊讶于有多少人忘记将“ID”列设置为主键。他们将其设置为自动增量，而不是主键。

【解决方案2】：

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

性能取决于：

这些查询进行了多少次联接
您的索引设置得如何
机器中有多少 RAM
处理器的速度和数量
硬盘驱动器的类型和主轴速度
查询返回的行大小/数据量

【讨论】：

【解决方案3】：

一些结论：

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

comment_id
rate

因此，您可以为需要的任何评论选择费率，聚合表的总行数会少得多。

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

user_id
vote_type

根据您选择的或 noSql 存储，数据可能完全存储在内存中，所有选择/更新操作都会非常快速地工作

【讨论】：

【解决方案4】：

表的大小不影响SELECT 查询并不完全正确。对于大表，我建议使用 TokuDB。

在这两种情况下，当您想要DELETE 一些数据时都会出现问题。此时，您有 2 个选择：集群键或开始考虑不同的架构（水平分片可能是一个好方法）：

【讨论】：