我们有一个 MySQL 实例，大部分时间都运行良好。然而，我们有时会观察到奇怪的行为。发生的情况是 MySQL 连接突然达到限制（当前设置为 1000）并且 MySQL 几乎停止。当我们检查此服务器的图表时，会观察到以下内容：
该图像来自运行 MySQL 导出器的 Grafana 实例。困扰我的是为什么不重用缓存中的线程。另一个问题是为什么缓存中的线程突然降为零但同时没有创建新线程（根据第二张图 - 蓝线保持为 0）。
最终，我的目标是了解为什么突然使用 1000 个连接，以及这是 MySQL 还是应用程序的问题。这是 MySQL 文档关于线程的说法：
服务器应缓存多少线程以供重用。当客户端断开连接时，如果那里的线程少于 thread_cache_size，则客户端的线程将被放入缓存中。如果可能，通过重用从缓存中获取的线程来满足对线程的请求，并且只有当缓存为空时才会创建新线程。
任何帮助或指导将不胜感激！
雷霆万钧。或者，一家杂货店里的人太多了，没人能移动他们的购物车。
什么时候
Threads_running是 349，他们每个人都在等待，等待，等待一小部分 CPU 和少量的 I/O 以及……结果是他们都需要“永远”才能完成。与此同时，其他试图进入的人被允许进入，因为你有这么高max_connections的等等。但是，这并不能解释是什么将牛群推下了悬崖。它可能是一件微不足道的事情，就像一个大人物
SELECT恰好阻止了牛群通常所做的那样。你有没有打开慢日志？具有较低的价值
long_query_time？如果是这样，您可能已经在慢日志中找到了答案。由于您没有惊慌并重新启动，因此缓慢的 Select（如果它确实存在）将在 slowlog 中。根据图表，我猜它可能需要 80-110 秒的时间。至于浸入
Threads_cached，这有点复杂。首先，让我解释一下非浸渍部分。在“事件”之前，建立了大约 200 个连接；每个都持续足够长的时间以连接“稳定”的 200 个。活动结束后，等待入场的人太多，将人数推高至约 350 人。
浪费
thread_cache_size = 500记忆；建议你降低到250。至于下降，我会做一些猜测。如此多的连接都在努力完成工作，以至于新连接被拒绝访问。（这可能是MySQL故意为之，也可能是大家争抢各种互斥锁的副作用。）
max_connections = 1000拥有;也是不明智的 这只会邀请这样的场景。取而代之的是，当出现问题时让客户“承受压力”——拒绝访问 MySQL。此外，这更容易说“糟糕，遇到问题请稍候，请不要再次按发送，也不要按刷新！” 或者干脆给一个“500”。底线：我认为慢日志可以指出事件的原因。