我们遇到了一个问题，查询一个包含大约 5000 万行且索引大小为 4 GB（表大小约为 6 GB）的表会导致数据库服务器交换内存，并显著降低速度。我非常确定这与临时表大小超出范围并被交换到磁盘有关。
如果我将数据库服务器的 RAM 从 32 GB 升级到 64 GB，我想知道 MySQL 数据库是否能够充分利用这些额外的内存而不进行交换。我查看了一些变量（例如 KEY_BUFFER_SIZE 等），它们似乎支持设置超过 64 GB 的值。但是，MySQL 文档说 tmp_table_size 的最大值为 4 GB。
那么内存升级是否值得？“查询大表”问题是否会因此受益，还是会因为 4 GB 的限制而无济于事？我知道可能还有其他解决方案，例如重新构建表以使用不同的方式进行分区等……但如果不对表进行任何更改，增加内存是否有帮助？
另外，一般来说，当从 32 GB RAM 转移到 64 GB 时，是否还有其他与内存相关的变量是 MySQL 无法利用的？
我们使用 64 位 Linux（Ubuntu）作为数据库服务器。
谢谢，盖伦
答案1
如果您使用的是 InnoDB，则要设置的最重要的变量是innodb_buffer_pool_size。我会将其设置为系统内存的大约 80%。一旦您的缓存在使用一段时间后预热起来，您最活跃的数据（工作数据集）将位于内存中（innodb_buffer_pool_size），并且您对它的操作应该非常快。有了 64GB 的内存，您肯定可以在那里放很多东西。内存对于 DB 服务器来说始终是物有所值的。
答案2
是的 - 如果您使用 InnoDB 并且具有读取密集型工作负载，您绝对可以利用大量 RAM [假设您的数据集适合内存 - 您的服务器将会非常快]。
我在 8-16 GB 的服务器上使用带有 InnoDB 存储的 MySQL，并且工作集适合内存。
答案3
在花钱购买内存之前，也许值得花一些额外的时间和精力来研究导致系统交换的原因？
即使将整个表、索引和最大 temp_table 加载到内存中，32GB 内存仍有足够的可用内存。快速搜索后，出现了以下两篇可能相关的文档：
答案4
如果您认为这是由于创建了一个非常大的临时表，您可能需要考虑改进查询以避免临时表的方法。
您可以在 Stackoverflow 上发布一篇包含模式、查询、解释计划和问题的一些详细信息的帖子。