为什么我们关心高并发的MySQL性能？

在许多MySQL 基准测试中，我们可以看到性能与相当高的并发性水平相比。在某些情况下，达到4,000个或更多并发线程，这些线程尽可能快地敲击数据库，导致数百甚至数千个并发活动查询。
问题是它在生产中有多常见？用于并发的典型度量标准定义为实际处理的查询数量是“Threads_Running”，您可以轻松地为生产系统查看：

根据我的经验，该领域的大多数系统将以正常负载不超过低数并行运行。如果运行的线程数超过50-100并且在那里停留了很长时间，许多人都会设置监控设置。

因此，如果人们没有真正运行具有高并发性的MySQL，那么MySQL如何以高并发性执行真的很重要，还是仅仅是推销新软件版本的噱头？

高并发性能很重要，但出于其他原因。真实世界系统与基准测试不同，它们通常没有固定的并发性，相反，它们必须服务于请求，因为它们可以接近“随机到达”但实际上在实践中可能要复杂得多。在几乎同时（通常在外部系统上发生某些停顿，例如memcached服务器）或数据库服务器本身体验“微停顿”时，有可能突发查询到达数据库服务器。可能导致查询的累积。这样的构建可以很快发生。

想象一下例如一些高容量的Web系统。它可能有100个Web服务器，每个服务器都配置了Apache，最多可以同时运行100个apache子节点，每个子节点可能会打开与MySQL服务器的连接…最终会有大量高达10K的连接和可能正在运行的查询。现在想象一下，通常我们从Web级别进入30K查询/秒，平均延迟大约为1ms，这需要同时运行大约30个查询。想象一下，现在数据库的停顿时间只有100毫秒 - 你很可能甚至不会用肉眼看到它。考虑到我们的流入速率，预计会有3000个查询需要备份，这很可能来自1000个或更多连接。

这就是High Concurrency的表现是生与死之间的差异。看一下这些图表 MySQL社区服务器的蓝线只有其1/4的峰值并发性能为1000，而带有线程池插件的MySQL企业版红线仍然非常接近峰值。

在实践中，这将意味着一个服务器将能够非常快速地处理积压并且在这样的停顿之后恢复，其他服务器将被压低并且可能无法服务于在水下越来越高的请求的流入。在这种情况下，某些系统可能永远不会恢复，直到重新启动Web服务器或从其他方式加载它们，其他系统将恢复但需要花费更多时间并且会产生更多用户影响 - 所有较慢的响应将导致用户提交较少的请求系统减少负荷。
是的 高并发性能很重要，因为它可以帮助系统处于困境。但是，低和中并发性能也很重要，因为这将在正常运行期间定义系统性能。

PS我认为有兴趣让人们看到高并发人员在现场运行服务器的程度。如果您可以为加载的生产服务器运行上面的命令（但是没有遇到困难），我认为这将非常有趣。