1M记录时为select语句优化MySQL数据库：单独存储旧数据？

Posted 2023-04-15

【中文标题】1M记录时为select语句优化MySQL数据库：单独存储旧数据？

【英文标题】：Optimizing MySQL database for select statements when there are 1M records: store old data separately?

【发布时间】：2019-04-06 19:28:30

【问题描述】：

我有一个网站，用户可以在其中保持对话。每条评论都存储在 mysql 数据库中。 DB 有一个名为 comment 的表，其中包含一个指向对话的外键。 对话消息逐步返回给客户端，使用 "limit" 子句 限制行（这对我的问题很重要）。例如，

SELECT * FROM `messages` WHERE `user_to_id` = 1 and `conversation_id` = 4 limit 10,5

我的问题是下一个：如果 cmets 表中的记录太多，像上面这样的选择查询会更慢吗？ 如果是，一个好的做法是将旧记录存储在单独的表或服务器文件中，以便仅使用最近的 cmets 加速选择查询？

【问题讨论】：

如果您正确索引数据库，并以较小的批次加载数据（即您不会一次加载最后 10.000 个 cmets），应该没问题。 SQL 专为处理庞大的数据集而设计。

就像@Qirel 所说的，如今的 SQL 服务器旨在处理数百万或数十亿的记录，在索引时就可以了。这意味着它很可能可以很好地处理几 GB 或 TB 大小的表大小。为了更好地扩展，您可以使用分区来进一步改进。

谢谢你们。所以，不需要单独存放

“所以，没有必要单独存储” @Angel 分区会在 MySQL 中自动完成，它会生成更小的表文件..

索引胜过数据。这意味着即使是普通计算机也可以处理数百万或记录如果优化器使用了正确的索引。

【参考方案1】：

如果查询SELECT * FROM `messages` WHERE `user_to_id` = 1 and `conversation_id` = 4 limit 10,5 已经返回最新 消息，那么您的limit 子句可确保速度，因为您限制了结果数据集，所以保留数百万条消息应该没有问题。

【讨论】：

谢谢。如果其他用户没有相反的评论，稍后我会接受这个答案

事实上 LIMIT 应该与 ORDER BY 结合使用，否则结果是不确定的（随机）@Angel

“保留数百万条消息应该没有问题，因为您限制了结果数据集” 这不是真的LIMIT 1000000, 1000 很慢，因为服务器需要存储和获取1001000 记录以再次丢弃1000000 以保留1000.. 在大型表上使用并不是最佳选择。

@RaymondNijland 阅读了我的回答：如果 [...] 已经返回最新消息，我的意思是 Angel 一定是作为示例输入了它并且没有添加ORDER BY，否则他将运行一个带有随机排序消息的系统

Limit doesn't always ensure performance.