为什么数据库连接池不采用 IO 多路复用？ _数据库连接池

这是一个非常好的问题。IO多路复用被视为是非常好的性能助力器。但是一般我们在使用DB时，还是经常性采用c3p0，Tomcat connection pool等技术来与DB连接，哪怕整个程序已经变成?.NETty为核心。这到底是为什么？
先纠正一个常见的误解。IO多路复用听上去好像是多个数据可以共享一个IO（socket连接），实际上并非如此。IO多路复用不是指多个服务共享一个连接，而仅仅是指多个连接的管理可以在同一进程。在网络服务中，IO多路复用起的作用是一次性把多个连接的事件通知业务代码处理。至于这些事件的处理方式，到底是业务代码循环着处理、丢到队列里，还是交给线程池处理，由业务代码决定。
对于使用DB的程序来讲，不管使用多路复用，还是连接池，都要维护一组网络连接，支持并发的查询。
为什么并发查询一定要使用多个连接才能完成呢？因为DB一般是使用连接作为Session管理的基本单元。在一个连接中，SQL语句的执行必须是串行、同步的。这是由于对于每一个Session，DB都要维护一组状态来支持查询，比如事务隔离级别，当前Session的变量等。只有单Session内串行执行，才能维护查询的正确性（试想一下一组sql在不断增减变量，然后这组sql乱序执行会发生什么）。维护这些状态需要耗费内存，同时也会消耗CPU和磁盘IO 。这样，限制对DB的连接数，就是在限制对DB资源的消耗。
因此，对DB来说，关键是要限制连接的数目。这个要求无论是DB连接池还是NIO的连接管理都能做到。
这样问题就绕回来了，为什么DB连接不能放到IO多路复用里一并执行吗？为啥大家都用连接池？
【为什么数据库连接池不采用 IO 多路复用？】答案是，可以用IO多路复用——但是使用JDBC不行。JDBC是一个出现了近20年的标准，它的设计核心是BIO（因为199X年时还没有别的IO可以用）：调用者在通过JDBC时执行比如query这样的API，在没有执行完成之前，整个调用线程被卡住。而类似于MySQL Connector/J这样的driver完备实现了这套语义。
当然如果DB Client的协议的连接处理和解析稍微改一下：

将IO模式调整为Non-Blocking，这样就可以挂到IO多路复用的内核上（select、epoll、kqueue……）
在Non-Blocking实现的基础之上实现数据库协议的编码和解析

就可以实现用IO多路复用来访问DB 。实际上很多其他语言/框架里都是这么干的。比如Nodejs，see https://Github.com/sidorares/node-mysql2；或者Vert.X 的db客户端（https://github.com/mauricio/postgresql-async，不要在意这个名字，它实际上同时支持mysql和postgres）。只不过对于IO多路复用，数据库官方似乎都没做这种支持——他们只支持JDBC、ODBC等等这些标准协议。
那么为什么基于IO多路复用的实现不能成为默认的，官方的，而要成为偏门呢？
对于数据库开发者来说。这种用法在整体的用户里占有量非常小，所以也许不值当的花大力气。只需要把协议写清楚（比如https://dev.mysql.com/doc/internals/en/client-server-protocol.html），就可以做实现。那么社区的有兴趣的人自然就可以去做。
另外一个原因是体系的支持。简单来讲，如果没有一个大的Reactive的运行环境， IO多路复用的使用会非常受限。
IO多路复用之所以能成立，是需要整个程序要有一个IO多路复用的驱动代码——就是select的那句调用。整个程序必须以这个驱动代码为核心。这样就对整个代码的结构产生重大的影响。这种影响是没法用简单的接口抽象的。
JAVA Web容器之所以可以使用NIO是因为NIO可以被封装到容器内部。Web容器对外暴露的还是传统的多线程形式的Java EE接口。
如果DB和Web容器同时使用NIO ，那么调用的DB连接库与必须与容器有一个约定描述DB的连接管理如何接入Web容器的NIO的驱动代码。在Java这个大环境下，不同人，不同的容器写的代码不同；又或者，不使用任何常见的容器，而是自己用NIO去封装一个。这样是无法形成代码上的约定的。那么多个独立的组件就不能很好共享NIO的驱动代码。
上面这个用法假设整个程序应该共享一个NIO驱动代码。那么Web和DB可不可以各用各的呢？也是可以的，但是为了保证这两个NIO驱动代码不会相互block ，最好要分开两个线程。这样一来就会打破一般Web服务一个请求处理用一个线程的一般做法，会让程序变得更复杂——你的业务代码和DB查询之间必须做跨线程数据交换。