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