我们有一个安装在两台不同机器上的MySQL服务器，分别是测试服务器和生产服务器，这两个窗口都是Web应用程序使用的窗口。
问题在于，执行某些查询时，两台计算机之间存在巨大的性能差异（生产服务器是速度较慢的服务器）。两台服务器中的MySQL版本相同，甚至配置文件也相同（唯一的区别是数据的路径以及生产服务器除了错误外不记录任何东西）。我所说的性能差异要大3或4个数量级（例如，测试服务器中的查询执行时间为0.2 s，而生产服务器中的查询执行时间为84 s）。
令人讨厌的查询大量使用了带有“ WHERE [...] IN [...]”的子句，据我所知，它们通常非常慢，应将其替换为JOIN。但是，我们使用的MySQL版本是5.6.19，它会自动优化那些查询，这就是为什么它们在测试服务器中能快速执行的原因（而且它们属于程序的一部分，我们无法更改，因此我们无法手动对其进行优化）无论如何）。
就像我说的那样，MySQL的安装和配置是相同的，因此对于问题可能出在哪里我一无所知。一方面，我怀疑这一定是某种配置问题，因为程序和DB相同，另一方面，由于配置相同，所以这没有意义。
服务器上的一些数据：
测试服务器：
- 英特尔酷睿2四核Q9400 @ 2.66GHz
- 8GB RAM
- Windows Server 2008 R2标准
生产服务器：
- 英特尔至强E5530 @ 2.40GHz
- 5GB RAM
- Windows Server 2012 R2标准
编辑：我忘了说一件重要的事情：还有更多的查询正在执行，这些查询使用“ WHERE ... IN”子句作为“违规”子句。它们在两台计算机上都可以快速执行，这表明我已经通过MySQL对其进行了优化。如果这是实际问题（我不确定），那么对某些查询进行优化（而不对其他查询进行优化）的事实对我来说是个谜。
编辑＃2：这是两个服务器的配置文件：http : //pastebin.ca/2834906
编辑＃3：这是慢速查询之一的解释：https ://mariadb.org/ea/v36zj EXPLAIN在测试和产品中完全相同。查询本身在这里：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 innodb_buffer_pool_size应该多大？
当我们更新生产服务器中的值时，我将发布“真实”结果。
谢谢大家。
解决了
因此，我们终于在产品中对此进行了测试，这就是我之前评论的问题。我将innodb_buffer_pool_size的值放在321M中，这是我们使用的SDK的供应商推荐的值，即使根据前面的链接，对于这种大小和使用率的DB，它的值应该在3G左右。
不过，我仍然有一个疑问：321的值是一个无效值（太小），因此MySQL采用了另一个值。我的怀疑是，它使用了之前的有效数字，测试中为321M，产品中为182M，因此速度有所不同。只是出于好奇，但我想知道这是否正确。
再次感谢大家的帮助。