我们有很多 MySQL 选择查询来满足某些报告需求。大多数都不太复杂，通常包括 1. 五到六个连接语句 2. select 子句中的三到四个内部查询。
所有指标在生产环境中均已正确到位。我们已经多次检查了解释查询语法，它们都没有问题。
一些查询在响应时间方面表现得非常奇怪。相同的查询有时会在不到 500 毫秒的时间内返回（这表明所有索引都工作正常），当我们在 1 分钟左右运行它时，它会给出响应时间较长的结果（从 5-6 秒到 30 秒不等） .) 有时（大约二十次中有一次..）它会给出超时错误。
这可能是由于服务器负载造成的 - 但高方差如此频繁，以至于我们认为需要设置其他方法来解决它。
有人可以告诉我还能做什么吗？
谢谢，
苏米特
这种行为通常是由堆栈中的瓶颈引起的。
就像大楼里的旋转门一样——门一次只能进1个人，每个人需要3秒；只要人们到达的速度不超过每 3 秒 1 人，您就不知道这是瓶颈。如果人们在短时间内以更快的速度到达，队列会稍微增长，但很快就会消失。如果一小时内每 2.5 秒就有 1 人到达，队列就会变得难以管理，并且可能需要比这 1 小时更长的时间才能消失。
您的数据库系统由一条带有旋转门的长走廊组成 - 大多数门可以并行操作，但它们都是有限的。
（抱歉这个垃圾类比，但我发现用现实世界的图像来可视化这些东西很有帮助）。
如果查询在其性能配置文件中显示出很大程度的差异，我会查看系统性能监视器（Linux 中的 top，Windows 中的 Perfmon）并尝试将缓慢的性能与系统的行为关联起来。如果当查询速度减慢时，您发现 CPU 利用率突然飙升，这可能是您的瓶颈；如果您发现磁盘吞吐量突然激增，您可能会查看那里。
一旦你对瓶颈有了假设，你就可以寻找解决它们的方法——使用硬件来解决问题通常是最便宜的。