MySQL/MariaDB在多个核上运行单个查询

Question

我有一个非常强大的数据库服务器，大约有24个核心和48 GB的RAM。我们将运行MariaDB 10.0作为数据库引擎。我的所有表都运行在InnoDB工程上，我有几个查询在大型表上使用了相当广泛的联接，因此自然比较慢。我正在努力做的一件事是尝试利用多核的力量。以下是我的观察：

1. 如果我并行地运行两个查询，那么我可以看到两个核心正在被使用。
2. 如果我运行一个查询，我发现只有一个核心被100%地使用。

这是正常的行为吗？我的意思是，在MariaDB/MySQL中没有办法为一个查询使用多个核心吗？如果一个单一的重查询能够通过使用多个CPU核来更快地运行，那将是很棒的。

我确实尝试过搜索多个论坛，并且使用过不同的参数，比如Innodb_thread_cocurrency，但是到目前为止还没有能够在多个核上运行一个查询。

有没有其他引擎可以帮助我做到这一点(我目前正在阅读关于XtraDB的文章)？

更新：

其实我是在分析社交媒体的数据。因此，想象一个拥有2-3百万推特的数据库。当然，我们谈论的是与USer数据、哈希标签、图像、链接等相关的表。在某些情况下，有些查询需要对多个表进行一些联接，而且查询速度很慢。因此，想象一下，例如，一个仪表板查询具有5-6个不同的查询。当单个用户登录时，这会在单个核心上加载，整个核心将被使用n秒钟。如果我有12个核心，假设12个用户同时尝试访问系统，那么我就有了一个严重的瓶颈。我完全理解，像切分、集群、分布式DB、分区这样的选项可以帮助我。但是现在，在我看横向扩展(我介绍了更多的服务器)之前，我正试图了解如何最好地垂直缩放一个系统。使用多个核本来是一个很好的选择，但我想我现在明白了，MySQL本身并不是这样设计的。我想我将开始研究各种(可能的架构)来将DB扩展到多个实例上。

Answer 1

虽然这条帖子已经有半年多的历史了，但其中的一些评论还是引起了一些关注。作为一个核心数据库性能调谐器，我想在这里添加一些输入：

1)在撰写本文时，MariaDB和MySQL不支持在多个处理器上运行单个查询(当然，除非您正在讨论分片)。但这并不意味着他们将来不会支持它。

2)并行查询可以在其他关系数据库管理系统( DB2、Oracle、SQLServer、Postgres等)中实现，是数据仓库等环境中的一个重要功能。

3)对于长时间运行的查询，通常情况下，并行化会缩短执行时间，但改进可能不是线性的。因此，如果说“一个查询使用多个核使其工作得更快是不合理的”，这是不正确的。对于某些工作量来说，这是非常有意义的，除非我们对“工作更快”有不同的定义。

4) Bottelnecking CPU并不一定意味着“您正在以错误的方式使用数据库”。是的，的确有些人编写了可怕的查询(或驱动查询的过程)并将数据库窒息而死，但这完全是另一个问题。

5)并行性会降低并发性。如果您的目标是支持更多的用户(即更高的并发性)，那么您将不得不放弃在多个处理器上运行查询(或者每个查询只在较少的处理器上运行)。这是你需要做的一笔交易。冒着过度泛化的风险，您可能希望OLTP环境查询以串行方式运行，而OLAP查询则希望并行运行。

干杯!

Answer 2

正如Mjh所解释的，如果CPU是瓶颈，那么您必须以错误的方式使用数据库。

InnoDB不支持单个查询的并行化。您可能可以通过在多个物理驱动器中扩展表空间实现某种类型的并行化(但我甚至不确定性能是否是此特性的主要目标，如果这样做有任何改进，那么当IO成为瓶颈时，它就会这样做)。

Answer 3

有些查询有部分解决方案。Innodb是高度优化的，以运行大数字{ 1000‘s}的小{50 -少1000行}请求。因此，让我们使用一个简单的任务{将一个100 M行表复制到另一个表}。简单的方法是插入..。选择。从..。然而，这样做将运行很长时间，如果中断回滚需要更长的时间。

现在，使用相同的问题，编写一个小过程，在表中一次遍历PK 1000行。这会运行得更快，因为进程主要是包含内存的，如果中断回滚几乎是即时的，并且您可以重新启动被中断的位置。

现在，采取这一过程，并同时运行它两次，一个在上半年的范围和2个在下半场。因为INNODB具有行级锁定，所以运行速度几乎是单机的两倍。

现在，创建一些经常醒来的事件，并为它们各自的线程运行过程。如果我有一个带有英特尔处理器的16核心服务器，我可以运行10个并发线程，并且看到CPU在1000%的顶部。在过去4年的生产中，我一直在运行这个。它只需要<10个表和<10个过程来支持它。作为一个额外的好处，其中一个过程将输出%%的线程完成。

任何遍历一个数值范围的全部或部分的sql都可以使用这种方法。它包括组中第一列为数字的组。所以，不是针对所有查询的解决方案，而是对于适用于这些查询的查询，我们通常可以减少5倍到10倍的时间。在许多情况下，顶部基本上没有I/O等待，因此其他查询受到的影响最小。