我的服务器不断因 MySQL 导致的 OOM 错误而崩溃。我确信此网站上有一个查询是错误的、太长的，并导致了此问题。我的服务器和 MySQL 日志显示几乎没有压力，直到出现峰值和问题。我真的很想找出这个有问题的查询并修复它。我觉得 mysql 调优一个原本很好的生产服务器以应对一个糟糕的查询（无论如何我都想删除它），这是一种很奇怪的做法。
我设置了慢查询日志，但这个问题查询从未出现在日志中，我相信因为查询从未完成，所以服务器首先崩溃了。我该如何记录或识别这个有问题的查询？
仅供参考：此网站上还有其他查询导致了此问题，我确实识别并修复了它们。它们通常是因为“BETWEEN ::startTime AND ::endTime”之类的子句而发生的，并且错误地将 ::startTime 设置为 0，导致时间跨度过大。
有人建议我使用 EXPLAIN，我理解这一点，问题是我不知道要“EXPLAIN”什么查询：）。
任何关于如何识别此查询的建议都将不胜感激。谢谢！
答案1
我有一个疯狂的建议给你。
我在 DBA StackExchange 上写了一篇文章轮询进程列表并告诉你在任意时间间隔内性能最差的 20 个查询。这比慢查询日志更好，因为慢查询日志只会记录已完成的查询。我的方法会即时捕获当前正在运行的查询。
我在去年年中实现了这个目标基于此 YouTube 视频。
答案2
我在 Percona Toolkit 中创建了 pt-stalk 工具，以帮助诊断在您不注意时发生的问题。它不仅可以帮助您捕获有问题的查询，还可以收集足够的信息，让您确定该查询是否是问题所在——如果不是，那么可能是其他原因。
答案3
为了补充其他答案，我想指出Percona 工具包这是我用于 MySQL 性能分析的首选工具。请查看pt-查询-摘要