配置连接池是开发人员经常犯的错误。配置池时需要理解几个原则（对于某些人来说可能违反直觉）。
想象一下，您有一个网站，虽然可能不是 Facebook 规模的，但仍然经常有 10,000 个用户同时发出数据库请求，每秒处理约 20,000 笔交易。您的连接池应该有多大？
你可能认为连接池越大越好！
问题不在于有多大，而在于有多小！
在没有任何其他更改的情况下，仅减少连接池大小即可将应用程序的响应时间从约 100 毫秒减少到约 2 毫秒，提高了 50 倍以上。
观看来自 Oracle Real-World Performance 小组的这段简短视频（点击标题）
同理，为什么仅使用 4 个线程的nginx Web 服务器就可以远远优于具有100 个进程的Apache Web 服务器？
即使是只有一个 CPU 内核的电脑，也能 "同时 "支持数十或数百个线程。但我们都[应该]知道，这不过是操作系统利用时间切片魔法玩的把戏。实际上，单个内核一次只能执行一个线程，然后操作系统会切换上下文，让该内核执行另一个线程的代码，以此类推。在单个 CPU 资源的情况下，顺序执行 A 和 B 总比通过时间切分 "同时 "执行 A 和 B 快，这是计算的基本定律。一旦线程数超过 CPU 内核数，增加线程的速度只会更慢，而不会更快。
资源有限
虽然不像上面说的那么简单，但也差不多了。还有其他一些因素在起作用。我们可以将数据库的主要瓶颈归纳为三个基本类别：CPU、磁盘和网络。我们可以把内存也加进去，但与磁盘和网络相比，带宽相差几个数量级。
如果我们忽略磁盘和网络，情况就会很简单。在一台有 8 个计算核心的服务器上，将连接数设置为 8 就能获得最佳性能，而超过这个数后，由于上下文切换的开销，速度就会开始变慢。但我们不能忽视磁盘和网络。数据库通常将数据存储在磁盘上，磁盘传统上由旋转的金属板组成，读/写头安装在步进电机驱动的机械臂上。读/写头一次只能位于一个位置（为单次查询读/写数据），必须 "寻道 "到新的位置才能为不同的查询读/写数据。因此会产生寻道时间成本和旋转成本，即磁盘必须等待数据在盘片上 "再次旋转 "才能读/写。缓存当然在这方面有所帮助，但原理仍然适用。
在这段时间内（"I/O 等待"），连接/查询/线程只是被 "阻塞"，等待磁盘。而在这段时间里，操作系统可以通过为另一个线程执行更多代码来更好地利用 CPU 资源。因此，由于线程在 I/O 时会被阻塞，我们实际上可以通过连接/线程数量大于物理计算核心数量来完成更多工作。
多多少？我们拭目以待。至于多多少，还取决于磁盘子系统，因为较新的固态硬盘驱动器没有 "寻道时间 "成本或旋转因素。不要受骗上当，认为 "固态硬盘速度更快，因此我可以拥有更多线程"。这完全是180度的倒退。速度更快、无寻道、无旋转延迟意味着阻塞更少，
因此更少的线程（更接近核心数）比更多的线程性能更好。
只有当阻塞为执行创造机会时，更多线程才会有更好的表现。
网络与磁盘类似。当发送/接收缓冲区填满并停滞时，通过以太网接口向外写入数据也会造成阻塞。万兆以太网接口的阻塞小于千兆以太网接口，而千兆以太网接口的阻塞小于百兆以太网接口。但就资源阻塞而言，网络是第三名，有些人在计算时经常忽略它。
在上述 PostgreSQL 基准中，您可以看到 TPS 率在连接数达到 50 个左右时开始趋于平稳。在甲骨文的上述视频中，他们展示了将连接数从 2048 降到 96 的过程。我们认为即使是 96 个连接也可能过高，除非您使用的是 16 核或 32 核的服务器。
设置数据库连接池的公式
下面的公式是 PostgreSQL 项目作为起点提供的，但我们相信它在很大程度上适用于所有数据库。您应该测试您的应用程序，即模拟预期负载，并围绕这个起点尝试不同的池设置：
连接数 = ((core_count * 2) + effective_spindle_count) |
猜猜这意味着什么？
你有台只有一个硬盘的 4 核 i7 服务器，运行的连接池应该是9 = ((4 * 2) + 1).
整数为 10。
看起来少吗？试试看吧，我们打赌，在这样的设置下，您可以轻松处理 3000 名前端用户以 6000 TPS 的速度运行简单查询。
如果运行负载测试，您可能会发现 TPS 率开始下降，而前端响应时间开始攀升，因为您（在给定的硬件上）将连接池推到了 10 以上。
为了避免死锁而计算池大小是一个相当简单的资源分配公式：
池大小 = T n x (C m - 1) + 1
其中T n是最大线程数，C m是单个线程持有的最大同时连接数。
例如，假设有三个线程 ( T n =3 )，每个线程需要四个连接来执行某些任务 ( C m =4 )。确保永远不会出现死锁所需的池大小为：
池大小 = 3 x (4 - 1) + 1 = 10
另一个例子，您最多有八个线程 ( T n =8 )，每个线程需要三个连接来执行某些任务 ( C m =3 )。确保永远不会出现死锁所需的池大小为：
池大小 = 8 x (3 - 1) + 1 = 17
这不一定是最佳池大小，而是避免死锁所需的最小值。
在某些环境中，使用 JTA（Java 事务管理器）可以通过将 getConnection() 中的同一连接返回给已在当前事务中持有连接的线程，从而大大减少所需的连接数。
总结
池大小最终取决于部署。
例如，混合有长时间运行的事务和非常短的事务的系统通常是最难使用任何连接池进行调整的。在这些情况下，创建两个池实例可以很好地发挥作用（例如，一个用于长时间运行的作业，另一个用于“实时”查询）。
在主要具有长时间运行事务的系统中，所需连接数量通常存在“外部”约束，例如作业执行队列仅允许同时运行一定数量的作业。在这些情况下，作业队列大小应“大小合适”以匹配池（而不是相反）。