我们遇到了一个问题,在这个查询大约有5000万行,索引大小为4 GB(表大小大约为6 GB)的表中,导致数据库服务器交换内存并显着减速。 我很确定这是与临时表大小超过,并交换到磁盘。
如果我从32 GB的RAM升级我的数据库服务器到64 GB的RAM,我想知道如果MySQL数据库将能够充分利用这个额外的内存,而不是交换。 我已经经历了一些variables(例如KEY_BUFFER_SIZE等),他们似乎支持超过64 GB的设置值。 但是,MySQL文档说tmp_table_size最大为4 GB。
那么内存升级是值得的吗? “查询大桌面”问题是否会从中受益,还是因为4 GB的限制而没有帮助? 我知道还有其他解决scheme,比如重组表格,以不同的方式进行分区,等等,但是不改变表格的任何内容,会有额外的内存帮助吗?
另外,一般来说,还有其他与内存相关的variables,当从32位移动到64位内存时,MySQL将无法使用这些variables。
我们使用64位Linux(Ubuntu)作为我们的数据库服务器。
谢谢,盖伦
如果你使用InnoDB,最重要的variables是innodb_buffer_pool_size
。 我将它设置为系统内存的大约80%。 一旦你使用了caching之后,你最活跃的数据(工作数据集)将会在内存中(innodb_buffer_pool_size),你的操作应该是非常快的。 有了64GB的内存,你绝对可以在这里安装很多。 内存对于数据库服务器来说总是不错的select。
是的 – 如果你使用InnoDB,并且读取密集型的工作量,你绝对可以利用大量的内存[假设你的数据集适合mem,你的服务器将会快速的发展]。
我在8-16 GB的服务器上使用带有InnoDB存储的MySQL,并在内存中安装工作集。
也许值得花一些额外的时间和精力来研究在把钱花在记忆之前是什么导致系统交换?
即使在将整个表,索引和最大temp_table加载到内存之后,32GB的内存仍会留下足够的可用内存。 快速search提出了这两个可能相关的文档:
如果您认为这是由于创build了一个非常大的临时表,那么您可能需要考虑如何改进查询以避免临时表。
你可以在Stackoverflow上发布一个包含模式,查询,解释计划和问题的一些细节的文章。