关于数据库连接池的一些思考
1.连接池简介
我们都知道数据库连接池的作用，初始时它首先向数据库申请多个连接，然后由它负责分配,管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是重新建立一个。
虽然知道了连接池的作用，但是更重要的一点是我们该如何配置，使得连接池的性能最优。而这里最为显著的问题就是如何设置连接池的连接数。
2.连接数该如何设置（参考https://blog.csdn.net/w05980598/article/details/78797310/）
假设某网站并发访问量为80000+，你觉得该设置多少合适呢？
10000吗？1000？100？NO，NO，NO，naive
实际上连接数的设置和用户的并发量完全没有关系，它仅仅依赖于如下几个方面的影响：服务器本身CPU的核数>数据库读写磁盘的性能>网络迟延
下面我们从操作系统和硬件的层面来进行理解：
即使是单核CPU的计算机也能“同时”运行数百个线程。但我们都[应该]知道这只不过是操作系统用时间分片玩的一个小把戏。一颗CPU核心同一时刻只能执行一个线程，然后操作系统切换上下文，核心开始执行另一个线程的代码，以此类推。给定一颗CPU核心，其顺序执行A和B永远比通过时间分片“同时”执行A和B要快，这是一条计算机科学的基本法则。一旦线程的数量超过了CPU核心的数量，再增加线程数系统就只会更慢，而不是更快。
-
若我们单独从CPU来考虑，不考虑IO等待、网络迟延，8核的CPU可以并行运行8个连接，此时的最佳设置即为8个连接，如果再多连接，只会增加线程的切换时间。
-
然而实际上数据库通常把数据存储在磁盘上，所以会造成IO时延，如果IO时延很大，这就十分需要多线程了，这样就可以先把该连接让给其他线程使用，这时就需要超过CPU核数的连接，这样才更合理。
那需要增加多少才合理呢？这就取决于你数据库磁盘的存取速度了，较新型的SSD不需要寻址，也没有旋转的碟片，存取速度更快，这时造成的延迟越小，从而需要的连接数越小；相反，若迟延越大，需要的连接数就越多。 -
网络也会造成时延，不过相比数据库的存取，它的影响要小得多，除非网络十分拥挤的情况下，就得重新设置增加连接数。
下面给出一个PostgreSQL提供的经验计算公式：连接数 = CPU核心数 * 2+ 有效磁盘数
这一公式其实不仅适用于数据库连接池的计算，大部分涉及计算和I/O的程序，线程数的设置都可以参考这一公式。
实际上当并发量很高时，我们只需要维护一个较小的连接池，和一个充满了等待连接的线程的队列。
如果你有10000个并发用户，设置一个10000的连接池基本等于失了智。1000仍然很恐怖。即是100也太多了。你需要一个10来个连接的小连接池，然后让剩下的业务线程都在队列里等待。连接池中的连接数量应该等于你的数据库能够有效同时进行的查询任务数（通常不会高于2*CPU核心数）。