jua*_*ena 8 mysql performance windows
我们在两台不同的机器上安装了一个 MySQL 服务器，一个测试服务器和一个生产服务器，都是 Windows，它被一个 web 应用程序使用。
问题是在执行某些查询时两台机器之间存在巨大的性能差异（生产服务器是较慢的一台）。两台服务器中的 MySQL 版本是相同的，甚至配置文件也是相同的（唯一的区别是数据的路径以及生产服务器除了错误之外不记录任何内容的事实）。我所说的性能差异要大 3 或 4 个数量级（例如，测试服务器中的查询执行时间为 0.2 秒，而生产服务器中的查询执行时间为 84 秒）。
违规查询广泛使用带有“WHERE [...] IN [...]”的子句，这是我的理解，它们通常很慢，应该用 JOIN 替换。但是，我们使用的 MySQL 版本是 5.6.19，它会自动优化这些查询，这就是为什么它们在测试服务器中执行得很快（而且它们是我们无法更改的程序的一部分，因此我们无法手动优化它们）反正）。
正如我所说，MySQL 的安装和配置是相同的，所以我完全不知道问题出在哪里。一方面，我怀疑这一定是某种配置问题，因为程序和数据库是相同的，另一方面，这没有意义，因为配置是相同的。
服务器上的一些数据：
测试服务器：
生产服务器：
编辑：我忘了说一件重要的事情：正在执行更多的查询，这些查询使用“WHERE ... IN”子句来区分“违规”的那些。它们在两台机器上都执行得很快，这表明 MySQL 正确地优化了它们。某些查询已优化而其他查询未优化这一事实对我来说是个谜，如果这是实际问题，我不确定。
编辑 #2：这是两台服务器的配置文件：http : //pastebin.ca/2834906
编辑 #3：这是慢查询之一的解释：https ://mariadb.org/ea/v36zj 测试和生产中的解释完全相同。查询本身在这里：http : //pastebin.com/VXgBxXmt它已用自动格式化程序格式化，所以可能不是很清楚。正如你所看到的，是相当长和复杂的。它不是手工生成的，而是由软件自动生成的，它使用标准SQL 的方言，具有一些功能。
另外，更多信息：我们通过减少生产服务器中的数据并删除数据库中大部分不会使用的旧数据来临时修补该问题。当然，这不是解决方案，因为我们还需要旧数据，而且将来会成为问题。DB 不是那么大：完整的 DB 是 1308MB，目前生产的缩减版本是 332MB。
更新：解决了？？
我想我已经解决了这个问题。我还没有测试过，因为生产服务器实际上正在使用，但可能的问题是参数“innodb_buffer_pool_size”，该参数设置为182M。实际上，配置文件中的行显示：innodb_buffer_pool_size=321 这是一个错误，因为它没有单位前缀，给出了一个无效值（根据文档，最小值为 5242880），然后将其置于先前的值. 测试服务器中的此值设置为所需的 321M。
正如我所说，我还没有完全测试它。我所做的是降低测试的价值并尝试应用程序。一切都变得更慢，我发布的特定查询在 3 分钟内执行。
我已经测试了一个更合理的 3Gb 值，我不知道这是否是一个好主意，所以如果有人对这个值有一些评论，我会很感激。
我的结论，3Gb 的“合理价值”以及我用于此的信息来自这两篇文章，尤其是第二篇：
MySQL 查询，2 个相似的服务器，执行时间相差 2 分钟
mysql innodb_buffer_pool_size 应该有多大？
当我们更新生产服务器中的值时，我将发布“真实”结果。
谢谢大家。
解决了
所以，我们最终在 prod 中测试了这个，这是我之前评论过的问题。我把innodb_buffer_pool_size的值放在了321M，这是我们使用的SDK厂商推荐的值，虽然按照之前的链接，对于这种大小和用途的DB应该在3G左右。
不过，我仍然有疑问：321 的值是无效值（太小），因此 MySQL 取了另一个值。我的怀疑是它采用了以前的有效数字，测试中为 321M，生产中为 182M，因此速度差异。这只是出于好奇，但我想知道这是否正确。
再次感谢大家的帮助。
我可能对此一无所知，但事情就是这样......
在您的问题和评论中，您陈述了以下内容：
两台服务器中的 MySQL 版本是相同的，甚至配置文件也是相同的（唯一的区别是数据的路径以及生产服务器除了错误之外不记录任何内容）
是的，数据库是相同的（实际上是将生产数据库转储到测试数据库中）。
类似结果：2.31Gb 稳定
您应该为查询提供 EXPLAIN 计划。由于数据相同，因此可能没有必要。
有几件事可能有所不同
我查看了Intel Core 2 Quad Q9400 @ 2.66GHz（测试）和Intel Xeon E5530 @ 2.40GHz（产品），发现了差异。
您可能认为 PROD 应该更快。
其内部总线速度可能是瓶颈。我会怀疑这一点，因为 TEST 具有更高的总线速度和 8 的总线乘数。什么是总线乘数？
微处理器的内部频率通常基于前端总线频率。为了计算内部频率，CPU 将总线频率乘以一定的数字，这称为时钟倍频。需要注意的是，为了计算，CPU 使用实际总线频率，而不是有效总线频率。要确定使用双数据速率总线（AMD Athlon 和 Duron）和四数据速率总线（从 Pentium 4 开始的所有 Intel 微处理器）的处理器的实际总线频率，对于 AMD，有效总线速度应除以 2，对于 AMD，有效总线速度应除以 4。英特尔。
基于此，AMD (TEST) 的内部总线速度至少是 Intel (PROD) 的 2 倍。
由于您使用相同的数据加载 TEST，因此可能会忽略一件事。我正在考虑指数统计。对于 TEST，索引统计信息将是相当新的。对于 PROD，如果索引表经历了大量 INSERT、UPDATE 和 DELETE，则索引表可能已过时。
在具有相同 mysql 版本、相同 mysql 配置、相同数据集甚至相同硬件的两台不同计算机上运行 SELECT 可能会受到所涉及表上的索引统计信息的影响。
我将在 PROD 和 TEST 上的所有表上运行 ANALYZE TABLE，然后尝试比较性能。
| 归档时间： |
|
| 查看次数： |
6575 次 |
| 最近记录： |