mysql 的请求处理模型

背景
php 和nginx 都是起一个master进程和多个pool子进程来处理，不同的是nginx采用异步非阻塞模型，一个子进程可以同时处理成千上万个请求无需等待，php本身则不行，因为php采用的是阻塞模型，一个子进程只能处理一个请求，未处理完就会阻塞等待。node也是采用了异步非阻塞模型从而实现高并发，异步就是代码可读性比较差，容易出bug。当然，php也不是不可以，php的老爹是c，c又是万能，所以本来没有写一个扩展进php也就有了，swoole就是！而最重要的mysql又是怎么处理请求的呢？
分析
MySQL的查询使用的是线程池。当有大量请求并发访问时，一定伴随着资源的不断创建和释放，导致资源利用率低，降低了服务质量。线程池技术，预先会创建一定数量的线程，当有请求达到时，线程池分配一个线程提供服务，请求结束后，该线程又去服务其他请求。 通过这种方式，避免了线程和内存对象的频繁创建和释放，降低了服务端的并发度，减少了上下文切换和资源的竞争，提高资源利用效率。在MySQL早期的版本中，处理连接的方式是One-Connection-Per-Thread,即对于每一个数据库连接，MySQL-Server都会创建一个独立的线程服务，请求结束后，销毁线程。再来一个连接请求，则再创建一个连接，结束后再进行销毁。但是，这种方式在高并发情况下，会导致线程的频繁创建和释放。当然，通过thread-cache，我们可以将线程缓存起来，以供下次使用，避免频繁创建和释放的问题，但是无法解决高连接数的问题。One-Connection-Per-Thread方式随着连接数暴增，导致需要创建同样多的服务线程，高并发线程意味着高的内存消耗，更多的上下文切换(cpu cache命中率降低)以及更多的资源竞争，导致服务出现抖动。相对于One-Thread-Per-Connection方式，一个线程对应一个连接，Thread-Pool实现方式中，线程处理的最小单位是statement(语句)，一个线程可以处理多个连接的请求。这样，在保证充分利用硬件资源情况下(合理设置线程池大小)，可以避免瞬间连接数暴增导致的服务器抖动。