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