关于数据库连接池一些归纳

在客户端与服务端之间，我们一般都会创建若干连接并提前放置到连接池中，从而需要时可以从连接池直接获取，数据传输完成后，将连接归还到连接池，从而减少频繁的创建和释放所造成的开销。

数据库连接池就是这样一种存在。连接资源在数据库端是一种非常关键且有限的系统资源。连接过多往往会验证影响数据库性能。数据库连接池可以负责分配、管理和释放数据库连接。跟threadlocal一样，这是一种空间换时间的一种策略，能够明显提升数据库操作的性能。但是对于数据库连接管理不善，也会影响到整个应用集群的吞吐量。连接池配置错误加上慢sql，会让一个系统瞬间进入服务超时假死宕机状态。

以我们熟悉使用的Druid为例，这是阿里巴巴的一款开源数据库连接池框架，还提供了强大的监控和拓展功能。当应用启动时，会初始化最小连接数，当外部请求到达时，先使用空闲连接。如果达到最大并发，就需要等待。

关于MIN和MAX连接数有以下情况：

MIN过小：出现过多请求排队等待获取连接。
MIN过大，造成资源浪费。

MAX过小：峰值情况任然有很多请求等待资源，并且不能充分利用连接池的优势。
MAX过大：导致数据库连接被占满，大量请求超时。影响应用，造成雪崩。

实际业务中，假如数据库配置最大链接数为100，一个请求为100ms，那么最大能够处理100000QPS。

连接数的创建受限与我们服务器操作系统的fd（文件描述符）数量限制，系统默认单个线程是1024个，该值可以适当调整，但如果无限制增加，会导致服务器在fd的维护和切换上消耗过多的精力，从而降低应用吞吐量。

一般来说，从经验上看，在数据库层面的请求应答最好控制在100ms以内，秒级的都会存在巨大的优化空间，以下是一些优化的方案：

1.建立高效且合适的索引。（根据业务相关）
2.排查连接资源未显示关闭的情况，比如使用threadlocal来连接数据库连接。

3. 合并几个条连接数据库的请求，有效减少连接次数。
   4.合理减少join的使用，如果join的表超过3张，那么需要考虑数据结构的设计合不合理了。
   5.应用层优化。数据结构优化、并发改造。
   6.使用临时表。在不断的嵌套查询中，已经无法利用现有的索引来提升查询的效率，所以把中间的结果保存到临时表，然后重建索引，再通过临时表进行后续操作。

来自《码出高效阿里开发手册》