代码之家 › 专栏 › 技术社区 › Sam

大型MySQL表

caching mysql

Sam · 技术社区 · 17 年前

我正在处理一个需要缓存分页“搜索”结果的问题: Paginating very large datasets

搜索工作如下:给定一个item_id,我找到匹配的item_id及其排名。

SELECT item.* FROM item, matches 
    WHERE matches.item_id=<item in question>
    AND item.id=matches.matched_item_id 
    ORDER BY match_rank DESC
    LIMIT x,y

如果结果早于,比如说,24小时,我可以按照客户的要求将项目及其匹配项重新索引到此表中。问题是,存储N个项目的500个结果(其中N是~100000到1000000)这个表变得相当大。。。50000000-500000000行。

MySQL能处理这个问题吗?我应该注意什么?

4 回复 | 直到 9 年前

Community Mohan Dere 9 年前

Partioning replication 是此场景的主要解决方案。

您还可以在中检查MySQL的其他缩放技术 a question I previously asked

dkretz 14 年前

同意上述意见。在这里要非常小心,通过反规范化避免过早优化。

不要使用“选择*”。更多字段意味着更多磁盘读取。

如果可能,使用一个只写的表(即不更新也不删除),这样mysql就不会重用删除的空间和重新填充索引。

确保索引字段尽可能短(但不能短)

编辑:我想到了更多的事情。。。

标准(也是最快的)MyISAM表类型除了插入顺序(通过填充删除的行进行修改)之外,没有任何方法以任何顺序维护记录,即没有聚集索引。但是,如果定期根据索引复制/重建表,则可以伪造该表,该索引对于在同一页面中对关联记录进行分组非常有用。当然新记录不会符合要求,但98%的表效率比默认值高。

熟悉配置设置,尤其是缓存大小。事实上,为了方便起见,不必担心缓存大小以外的任何其他设置(并了解它们各自是什么)。

始终运行“慢速查询日志”。它的开销很低,是所有补救措施的第一站。

在事情即将崩溃之前不要去规范化。

不可谈判。

你永远不会明白这一切;你永远需要学习比你知道的更多的东西。总是问“为什么”和“你的证据是什么”。(通常情况下,有些人读到的东西并不适用于你的情况。)

mepcotterell 17 年前

MySQL可以处理它。真正的问题是:它能在合理的时间内处理吗?这取决于您的查询。正如Eran Galperin在回答中所说的,研究分区和复制以实现优化。

Community Mohan Dere 9 年前

正如其他人所说,MySQL可以轻松地扩展以适应非常大的数据集,并且通常它将处理大型数据集(几百万行),而无需开发人员/dba的大量干预,只需进行一点合理的索引和查询优化。 @doofledorer 在避免过早优化方面是正确的。正如37个信号员所说,如果你的应用程序在T台上取得了成功,并且你遇到了数据库问题,那么这是一个很好的地方。

然而,我想用我自己的一个问题来反驳这个问题——你真的需要使用MySQL作为你的缓存系统吗?有很多地方可以容纳500个整数的列表,我的第一选择是会话中的服务器端。即使会话数据被写入磁盘,加载500 int的数组也不会那么慢,而且有很多策略可以使用内存缓存(如MemCache)来进一步加快加载速度。

在会话存储阵列中循环,执行10、20(或任何类型的页面),沿着“select item.*where id=X”的行进行单独的查询可能听起来很吓人——当然这会增加查询的物理数量,但它会很快变亮,特别是在加入MySQL查询缓存的情况下。

如果您使用基于会话的方法,您将从会话是基于状态的这一事实中立即获益。您不必担心清除过期数据—会话结束时,poof,它就消失了。而且,如果您坚持使用基于光盘的会话(我在这里假设PHP是服务器端语言),那么请记住光盘空间非常便宜。

最终,它成为易用性(在开发/维护方面)、可伸缩性和性能之间的权衡。我想说的是,你应该牢记,仅仅因为你在处理数据库查询的结果,并不意味着数据库是存储所有情况下结果的最佳方法——保持开放的心态!