mysql和innodb的线程模型是什么？

Question

我正在学习MySQL和InnoDB的架构，线程模型和可插拔引擎系统的结合让我感到困惑。据称MySQL实例是一个多线程的进程，InnoDB有多个后台线程，如主线程、io线程等来处理内核aio的回调。此外，我发现连接池是由MySQL层管理的，而不是由可插拔InnoDB层管理的。

那么MySQL线程如何管理连接和它们的请求，以及MySQL请求如何到达内核aio，它是否与InnoDB io线程协作？

Answer 1

连接被赋予自己的进程(或线程，取决于操作系统)。这个进程就像一个单独的进程一样运行，除了访问大量的缓存、表等。为了处理它们，有许多“互斥锁”。它们用于授予某个进程独占访问权限，例如，在buffer_pool或表缓存等中插入/删除某些内容。

在过去，Mutexes很少。例如，要对缓冲池执行任何操作，只需一个(或几个)互斥锁授予访问权限。当有一个或两个CPU时，这是可以的。但是当服务器有8个核心时，他们意识到这还不够细粒度。所以对互斥锁进行了一次大修。(IIRC，由Percona带头。)

由于这些互斥锁，4个进程可以“同时”工作，直到它们被彼此绊倒。超过8个内核-->吞吐量实际上下降了。(延迟达到了顶峰。)

随着新版本的出现，这个数字增加了。使用MySQL 8，它可能会超过64。

发生的另一件事是buffer_pools和table_open_caches的“实例”。这是一种将互斥锁拆分为多个互斥锁的简单方法。

我不太熟悉I/O线程模型。我怀疑线程(对于一个连接)以某种方式向另一个线程发出信号，让它来做这项工作。

此外，有几件事留给了后台任务:刷新到日志、从“更改缓冲区”更新索引块、预读、从buffer_pool刷新“脏”页、清理BTrees等。请注意，所有这些都将使用适当的互斥量，以便不会彼此干扰和各种连接进程。

“可插拔引擎”系统需要一种不同类型的争论--在通用处理程序和特定于引擎的代码之间。我怀疑这与互斥、后台线程等是正交的。

“连接池”将是另一个数组(或列表)，多个进程希望获取/释放该数组中的项。因此它有自己的互斥锁。