MySQL 中的多线程?

发布于 2024-09-26 12:13:46 字数 82 浏览 9 评论 0原文

MySQL 操作是多线程的吗?

具体来说,在运行选择时,选择(或连接)算法是否会生成多个线程一起运行?多线程会妨碍支持大量并发用户吗?

Are MySQL operations multithreaded?

Specifically, on running a select, does the select (or join) algorithm spawn multiple threads to run together? Would being multi-threaded prevent being able to support a lot of concurrent users?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

红墙和绿瓦 2024-10-03 12:13:46

根据 MySQL 8.0 参考手册常见问题解答:一般

是的。 MySQL 是完全多线程的,并利用所有可用的 CPU。并非所有 CPU 都可用;现代操作系统应该能够利用所有底层 CPU,而且还可以将进程限制在特定的 CPU 或 CPU 组上。
在 Windows 上,当前 mysqld 可以使用的(逻辑)处理器数量存在限制:单个处理器组最多可使用 64 个逻辑处理器。
多核的使用可以通过以下方式来看待:
单个核心通常用于服务从一个会话发出的命令。
一些后台线程对额外核心的使用有限;例如,保持后台 I/O 任务移动。
如果数据库是 I/O 密集型的(通过 CPU 消耗小于容量来表示),则添加更多 CPU 是徒劳的。如果数据库被分区为 I/O 绑定部分和 CPU 绑定部分,添加 CPU 可能仍然有用。

但不适用于单个查询。
并行执行只能通过修改查询来实现。可以在这篇文章中找到很好的例子 通过并行查询执行提高慢速查询性能

现在我们可以运行一些查询。第一个查询非常简单:查找每年的所有航班(在美国):

    select yeard, count(*) from ontime group by yeard

由于我们在 YearD 上有索引,因此查询将使用该索引。查询很简单,但是需要扫描 150M 行。该查询耗时 54 秒,仅使用 1 个 CPU 核心。然而,这个查询非常适合并行运行。我们可以运行 26 个并行查询,每个查询都会计算自己的年份。我使用以下 shell 脚本在后台运行查询:

    #!/bin/bash
    date
    for y in {1988..2013}
    do
      sql="select yeard, count(*) from ontime where yeard=$y"
      mysql -vvv ontime -e "$sql" &>par_sql1/$y.log & 
    done
    wait
    date

Start: 11:41:21 EST 2014

End: 11:41:26 EST 2014

所以总执行时间约为 5 秒(快 10 倍)。

According to MySQL 8.0 reference manual FAQ: General

Yes. MySQL is fully multithreaded, and makes use of all CPUs made available to it. Not all CPUs may be available; modern operating systems should be able to utilize all underlying CPUs, but also make it possible to restrict a process to a specific CPU or sets of CPUs.
On Windows, there is currently a limit to the number of (logical) processors that mysqld can use: a single processor group, which is limited to a maximum of 64 logical processors.
Use of multiple cores may be seen in these ways:
A single core is usually used to service the commands issued from one session.
A few background threads make limited use of extra cores; for example, to keep background I/O tasks moving.
If the database is I/O-bound (indicated by CPU consumption less than capacity), adding more CPUs is futile. If the database is partitioned into an I/O-bound part and a CPU-bond part, adding CPUs may still be useful.

But not for single query.
Parallel execution can be reached only by modifying queries. Good examples can be found in this article increasing slow query performance with parallel query execution:

Now we can run some queries. The first query is very simple: find all flights per year (in the US):

    select yeard, count(*) from ontime group by yeard

As we have the index on YearD, the query will use the index. The query is simple, however, it will have to scan 150M rows. The query took 54 seconds and utilized only 1 CPU core. However, this query is perfect for running in parallel. We can run 26 parallel queries, each will count its own year. I’ve used the following shell script to run the queries in the background:

    #!/bin/bash
    date
    for y in {1988..2013}
    do
      sql="select yeard, count(*) from ontime where yeard=$y"
      mysql -vvv ontime -e "$sql" &>par_sql1/$y.log & 
    done
    wait
    date

Start: 11:41:21 EST 2014

End: 11:41:26 EST 2014

So the total execution time is ~5 (10x faster) seconds.

如此安好 2024-10-03 12:13:46

MySQL 服务器中运行多个后台线程。此外,每个数据库连接都由单个线程提供服务。 MySQL 中未实现并行查询(使用多个线程进行选择)。

MySQL本身可以支持“大量并发用户”。例如 Facebook 就通过 MySQL 成功起步。

Several background threads run in a MySQL server. Also, each database connection is served by a single thread. Parallel queries (selects using multiple threads) are not implemented in MySQL.

MySQL as is can support "a lot of concurrent users". For example Facebook started successfully with MySQL.

夏の忆 2024-10-03 12:13:46

除了每个连接都有一个线程之外,还有几个管理进程也有自己的线程。这是 DBMS 中常见的一种安排。例如Oracle RDMS有系统监视器、数据库写入器等。
运动是缓存读取和延迟写入。

Besides each connection has a thread, there are several management processes which has it's own thread. It's an arrangement commonly seen in DBMS. E.g. Oracle RDMS has System Monitor, DB Writer and so on.
The sport is cached-reading and lazy-writing.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文