我们在两台不同的机器上安装了一个 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，目前生产的缩减版本是 …