数据库

我们按照性能、功能、管理、NoSQL扩展各个方面来一一介绍MariaDB的新特性。首先是性能方面的线程池。如果你短连接较多，如果你的数据库CPU压力过高，如果你想降低多个sleep线程白白占用机器内存，thread pool都能够缓解。

MySQL会给每个过来的客户端连接分配一个线程，专门用于跟这个客户端交互。但是，随着并发连接的增加，线程会越来越多。CPU的上下文切换，cache命中率下降以及锁的竞争都会加剧。为了缓解这个问题，MariaDB引入的线程池的概念。这个对业务开发人员来说并不是一个陌生的概念，甚至有些开发人员会说，这个特性早就应该加上了！其实这个特性在MySQL的Enterprise早就有了这个特性，需要付费才能使用。但是MariaDB是开源免费的。
当然线程池好处很多：
可以让MySQL维护的线程数降下来。很多MySQL DBA在show processlist的时候，经常会看到一堆不做事，一直sleep在那里的线程，如果使用了线程池，这个数量可以明显减少。
对于那些短连接，CPU bound的MySQL来说，是一个非常好的特性。MySQL不用每次在客户端发起连接的时候，临时申请一个新的线程，并且立刻就需要把这个连接的资源全部释放掉。
节省MySQL内存占用。线程多了，内存占用当然比较多。用线程池，可以把有限的内存让给更需要内存的buffer pool或者keycache使用。减少磁盘IO，提高系统的响应时间。
避免MySQL连接数不够。当mysql达到max_connections时，会拒绝连接。使用线程池的话，就可以不用担心这个问题了。

但是，事情总是有利有弊的，使用线程池在某些场景下并不会有多少性能的提升：
线程池技术要求相对较高。线程池在连接太多的时候怎么动态扩展，在链接减少的时候怎么收缩；线程池本身的开销怎样控制；是否能够利用OS原生的线程池来直接提供服务等一系列问题都是引入线程池需要考虑的。
线程相互等待的问题。如果有长链接和短链接同时存在，那么短链接可能要等到长链接执行完所有操作，才能被轮到，执行时间不可控。
MariaDB充分考虑和优化了thread pool的实现，并提供了一系列参数给用户调整线程池的配置(thread_pool_size, thread_pool_stall_limit, thread_pool_idle_timeout, thread_pool_oversubscribe )和一些状态值（threadpool_threads，threadpool_idle_threads）提供给用户查询线程池使用情况。从实现方面来看，MariaDB相对MySQL Enterprise的线程池会使用原生的系统提供的线程池，并且考虑到各个系统OS的特点，优化多路IO（IO multiplexing）接口的使用。