MySQL 服务器仅使用 48 个 CPU 内核中的 1 个进行 GROUP BY 查询答案

【问题标题】：MySQL server uses only 1 out of 48 CPU cores with GROUP BY queriesMySQL 服务器仅使用 48 个 CPU 内核中的 1 个进行 GROUP BY 查询
【发布时间】：2017-03-01 10:16:09
【问题描述】：

我有安装最新 MySQL 5.7 的高端 48 CPU 核心服务器

我有点惊讶，当使用 GROUP BY 执行查询时，无论我如何格式化我的查询，我只得到 1 个 CPU 核心用于该查询，htop 输出清楚地说明了这一点

当然，我可以同时执行多个查询，这就是我可以使用所有内核的方式，但似乎不太方便，并且不是每个查询都可以拆分以使用完整服务器的功能

是否有任何 MySQL 扩展或 SQL 提示允许在使用 GROUP BY 处理数据时使用多个内核？

【问题讨论】：

您使用的是哪个引擎？据我所知，只有 innoDB 完全支持多核 cpu
MySQL（目前）不支持一个查询多核。
@Christian Felix：我使用 InnoDB 引擎
@Solarflare 您能否提供一些指向您在其中找到此信息的文档的链接？
@Matthias 如果您事先知道，可以在How MySQL Uses Threads for Client Connections 找到它。每个连接一个线程，因此每个查询一个线程（除了磁盘访问）。它没有明确说它不会为查询创建额外的线程，但如果它支持这一点，它可能应该这样做，所以唯一的其他迹象是该信息不存在。但更难证明文档中没有（任何地方）的东西。

标签： mysql multithreading performance group-by

【解决方案1】：

正如 RolandoMySQLDBA 对Possible to make MySQL use more than one core? 问题所接受的回答所说：

我实际上与 MySQL 专家讨论了 innodb_thread_concurrency 在 2011 年 5 月的 Percona Live NYC 会议。

我学到了一些令人惊讶的东西：尽管有文档，但它是最好将 innodb_thread_concurrency 保留为 0（无限并发）。这样，InnoDB 决定了 innodb_concurrency_tickets 的最佳数量为给定的 MySQL 实例设置打开。

一旦你将 innodb_thread_concurrency 设置为 0，你就可以设置 innodb_read_io_threads 和 innodb_write_io_threads（都是从 MySQL 5.1.38) 到最大值 64。这应该会使用更多的核心。

这是我找到的关于如何让 MySQL总体上使用更多内核的最佳指南。

【讨论】：

您是否用实际查询测试过这个建议并确认，使用此设置后，您可以为一个 SQL 查询使用多个核心？
是的，我做到了。但是，我强调了一般的表达。这并不意味着在给定时间点的特定查询肯定会使用多个核心。
设置全局innodb_read_io_threads = 8 错误代码：1238。变量'innodb_read_io_threads'是只读变量
@weefwefwqg3 这不是动态变量，请将其放置到配置文件（my.cnf）或您的自定义（如果有）

【解决方案2】：

除了后台线程，一个连接将只使用一个 CPU 内核。这适用于GROUP BY、UNION、PARTITION，以及您可能认为它应该设法并行执行的任何其他操作。

该声明至少在 MySQL 8.0 和 MariaDB 10.2 之前适用于 InnoDB。

第三方软件可以使用多核：https://www.percona.com/blog/2014/05/01/parallel-query-mysql-shard-query/。

此外，MariaDB 10.2 中的“列存储”可能使用多个内核。

【讨论】：

【解决方案3】：

这是 mySQL 的一个众所周知的限制，这就是为什么 mysql 不常用于分析目的。

作为一种解决方法，您可以在 mysql 前面使用 Apache Spark（以分析闻名），这里：

Apache Spark 将成为“SQL 引擎”，您可以将其作为工作集群运行
mysql 将是一个简单的数据存储

我让你发现如何使用 Apache Spark，以及如何使用原生 JDBC 连接器。

此外，PrestoDB（来自 Facebook 的分析引擎）似乎也可以实现这一点 (https://prestodb.github.io/docs/current/connector/mysql.html)。

【讨论】：

OP 不了解手头的问题，但您甚至没有回答这个问题 - 相反，您建议使用 Apache Spark。 OP 错误地假设工作负载受 CPU 限制，因此他认为使用更多内核 == 更快的工作，但手头的问题是 I/O 限制的性能问题。无论使用多少个内核，都是 hdd/ram 子系统让一切变慢。在问题上投入更多的软件并不能使它更快，它使它成为维护的噩梦。您没有解释这个问题不是 MySQL 限制而是 I/O 问题，而是另辟蹊径。