mysql select查询中的响应时间不一致

我们有很多MySQL select查询来满足一些报告需求。大多数都很复杂，通常包括1。五个六连接语句2。select子句中的三个四个内部查询

所有索引都在生产环境中适当地就位。我们多次检查了explain查询语法，它们都正常

有些查询在响应时间方面表现得非常奇怪。同一个查询有时会在不到500毫秒的时间内返回，这表明所有索引都工作正常，当我们在大约1分钟后运行它时，它给出的结果的响应时间从5-6秒到30秒不等。有时候20次就有一次。。它给出了一个超时错误

这可能是由于服务器负载造成的，但这种高差异是如此频繁，以至于我们认为还有其他方法可以解决它

谁能告诉我还有什么要做的吗

谢谢

---

Sumit

这种行为通常是由堆栈中的瓶颈造成的

这就像建筑物中的旋转门——门一次可以容纳1人，每个人只需3秒钟；只要人们不是以每3秒超过1人的速度到达，你就不知道这是一个瓶颈。如果人们在短时间内以更快的速度到达，队列会稍微增加，但很快就会消失。如果有人以每2.5秒1人的速度到达一个小时，队列将变得无法管理，并且可能需要比这1小时更长的时间才能消失

你的数据库系统是由一条长长的走廊组成，走廊上有旋转的门——大多数门可以并行运行，但它们都是有限的

很抱歉用垃圾比喻，但我发现用真实世界的图像来形象化这些东西很有帮助

如果查询在其性能配置文件中显示出高度的差异，我会查看Linux中的系统性能监视器top，windows中的Perfmon，并尝试将缓慢的性能与系统的行为关联起来。当查询速度变慢时，如果您看到CPU利用率突然上升，这很可能是您的瓶颈；如果您看到磁盘吞吐量突然增加，您可能会看到

---

一旦你对瓶颈有了一个假设，你就可以寻找解决瓶颈的方法——用硬件解决这个问题通常是最便宜的

这种行为通常是由堆栈中的瓶颈造成的

这就像建筑物中的旋转门——门一次可以容纳1人，每个人只需3秒钟；只要人们不是以每3秒超过1人的速度到达，你就不知道这是一个瓶颈。如果人们在短时间内以更快的速度到达，队列会稍微增加，但很快就会消失。如果有人以每2.5秒1人的速度到达一个小时，队列将变得无法管理，并且可能需要比这1小时更长的时间才能消失

你的数据库系统是由一条长长的走廊组成，走廊上有旋转的门——大多数门可以并行运行，但它们都是有限的

很抱歉用垃圾比喻，但我发现用真实世界的图像来形象化这些东西很有帮助

如果查询在其性能配置文件中显示出高度的差异，我会查看Linux中的系统性能监视器top，windows中的Perfmon，并尝试将缓慢的性能与系统的行为关联起来。当查询速度变慢时，如果您看到CPU利用率突然上升，这很可能是您的瓶颈；如果您看到磁盘吞吐量突然增加，您可能会看到

---

一旦你对瓶颈有了一个假设，你就可以寻找解决瓶颈的方法——用硬件解决这个问题通常是最便宜的

谢谢你的指导，内维尔。将密切关注服务器负载和查询响应时间，并将在此处更新。感谢Neville的指导。将密切关注服务器负载和查询响应时间，并将在此处更新。