一个查询应该在多大程度上减慢整个系统的速度?

And*_*rew 5 mysql performance

这类似于我之前的问题,但更通用。我有一个具有 16GB 内存、16 个内核、据称是优质硬盘、RHEL 5、MySQL 5.0.x 的系统。是的,我知道,我们正在努力升级它。但这就是我们所拥有的。

我只是运行了一些带有大量插入和复杂连接的查询,这导致负载飙升至 6,通常为 1.10。人们开始报告该网站变得缓慢。这些都是 MyISAM 表,但这与行与表锁定无关 - 性能损失发生在与正在操作的表完全不同的一组表上。这不是关于“无法执行其他查询”,而是关于“系统上的其他一切都会变慢”。

我一直在尝试用谷歌搜索这个,但找不到其他资源说查询应该像这样增加服务器负载。所以我开始怀疑:这只是我吗?如果是这样,您有什么建议吗?如果没有,您有任何缓解建议吗?

Rol*_*DBA 4

复杂的连接可能是临时表使用的先兆。默认情况下,tmp_table_size设置为max_heap_table_size 的值(16M)。

对于任何给定的查询,一旦 tmp 表在 RAM 中达到 16M,它就会执行以下迁移

  • 查询暂停操作
  • mysqld会将整个16M的tmp表数据作为MyISAM表迁移到磁盘上
  • 查询将继续直至完成

您还必须记住基于磁盘的临时表将存放在哪里。默认情况下,基于磁盘的 tmp 表所在的文件夹在tmpdir中定义。

  • 对于 Windows,这将是C:\TEMPC:\TMP(环境变量TEMPTMP
  • 对于 Linux,这将是 /tmp

如果 mysqld 正在与操作系统竞争 tmpdir 使用,您应该很快就能感觉到,因为操作系统将开始交换以在系统临时文件夹中找到所需的肘部空间,而相关查询可能会尝试强制将 tmp 表强制放入相同的操作系统临时空间。

您可能需要研究以下一项或多项

  • 将 /tmp 挂载到 RAM 磁盘
  • 将 /tmp 安装到远离根分区的另一个磁盘
  • 将 tmp_table_size 和 max_heap_table_size 设置为 2K(这不是拼写错误,我说的是 2K)以强制 tmp 表快速转到 tmpdir,从而缩短 tmp 表内存到磁盘的迁移时间
  • 我在 StackOverflow 上写过这个

更新 2012-03-13 15:11 美国东部时间

将 tmp_table_size 和 max_heap_table_size 设置为 512M 太高了,非常危险。如果发生错误查询(尤其是 Cross Join(又名 Caretsian Join)),mysqld 将花时间将 512M MEMORY 表迁移到基于磁盘的 MyISAM 表,然后再继续处理查询。您可能需要显着降低该数字以强制临时表更快地写入磁盘。这是必须的,因为 tmp_table_size 和 max_heap_table_size 是针对每个数据库连接设置的。