我正在学习MySQL和InnoDB的体系结构，而将线程模型与可插拔引擎系统结合在一起会使我感到困惑。据称MySQL实例是一个具有多个线程的进程，并且InnoDB具有许多后台线程（例如主线程，io线程）来处理内核aio的回调。而且，我发现连接池是由MySQL层而不是可插入的InnoDB层管理的。
然后MySQL线程如何管理连接及其请求，以及MySQL请求如何进入内核aio，它是否与InnoDB io线程配合？
一个连接被赋予了自己的进程（或线程，取决于OS）。除了访问大量缓存，表等之外，该过程就像一个进程一样运行。要处理它们，有许多“互斥体”。这些用于授予对一个进程的独占访问权，例如，在buffer_pool或表高速缓存等中插入/删除某些内容。
[过去，互斥量较少。例如，要对缓冲池执行任何操作（一个或多个）即可获得Mutex授予的访问权限。当有一个或两个CPU时，这很好。但是，当服务器具有8个内核时，他们意识到这还不够精细。因此，对互斥锁进行了大修。 （IIRC，它是由Percona带头的。）
由于这些互斥锁，四个进程在彼此绊倒之前可以“同时”工作。超过8个核心->吞吐量实际上下降了。 （并且等待时间已经过去了。）
随着新版本的出现，这个数字增加了。对于MySQL 8，可能超过64。
发生的另一件事是buffer_pools和table_open_caches的“实例”。这是将互斥锁拆分为几个的直接方法。
我对I / O线程模型不太熟悉。我怀疑该线程（对于一个连接）以某种方式向另一线程发出信号以为此工作。
此外，后台任务还剩下几件事：刷新日志，从“更改缓冲区”更新索引块，预读，从buffer_pool刷新“脏”页面，清理BTree等。请注意，所有这些这些将使用适当的互斥锁，以免互相踩踏以及各种连接过程。
“可插拔引擎”系统需要另一种类型的震颤-通用处理程序和引擎特定的代码之间。我怀疑这与互斥锁，背景线程等正交。
“连接池”将是另一个东西的数组（或列表），并且多个进程希望获取/释放该数组中的项目。因此，它有自己的互斥锁。