数据库连接池的最大连接数不是越大越好，超时设置也不是越长越安全。真正合理的配置需要根据你的数据库服务器硬件、并发请求量、单个查询耗时来综合计算。一个常见的错误做法是直接把最大连接数设成500甚至1000，结果数据库CPU直接打满，响应反而变慢。正确的思路是：先压测，再计算，最后动态调整。下面我把这套方法论从头到尾讲透。

一、最大连接数到底怎么定

最大连接数（maxPoolSize）是连接池中允许同时存在的最大数据库连接数量。这个值设得太小，高并发时请求会排队等待，甚至抛出"无法获取连接"的异常；设得太大，数据库本身扛不住，每个连接都要占用内存和CPU资源，最终拖垮整个数据库实例。

一个实用的计算公式是：最大连接数 = (核心数 × 2) + 磁盘数。这是MySQL官方给出的经验值。比如你的数据库服务器是8核、4块磁盘，那么建议最大连接数设在20左右。但这只是数据库服务端的上限，你的应用端连接池还要在这个基础上打折扣，通常建议设为数据库最大连接数的50%-70%。

如果你用的是HikariCP（目前Java生态最主流的连接池），配置方式非常简单：

hikari.maximumPoolSize=20
hikari.minimumIdle=5
hikari.connectionTimeout=30000

如果你用的是Druid连接池，配置项稍有不同：

spring.datasource.druid.max-active=20
spring.datasource.druid.min-idle=5
spring.datasource.druid.max-wait=30000

二、超时参数的三个关键维度

超时配置不是一个参数，而是三个参数协同工作。很多人只关注其中一个，导致配置形同虚设。

第一个是连接超时（connectionTimeout），指的是从连接池获取一个可用连接的最大等待时间。如果30秒内拿不到连接，就抛异常。这个值建议设在10-30秒之间，太短会频繁报错，太长会让请求长时间挂起。

第二个是空闲超时（idleTimeout），指连接在池中空闲多久后被回收。HikariCP默认是10分钟，Druid默认也差不多。如果你的应用流量波动大，建议设短一点，比如5分钟，避免空闲连接占着资源。

第三个是最大生命周期（maxLifetime），指一个连接最多存活多久，到期强制关闭重建。这个参数非常关键，目的是防止连接因为数据库端超时、网络抖动等原因变成"僵尸连接"。建议设为比数据库wait_timeout短几分钟，MySQL默认wait_timeout是8小时，那你可以设30分钟：

hikari.maxLifetime=1800000

三、不同场景下的推荐配置方案

场景不同，配置策略完全不一样。我按三种典型场景给出具体数值。

场景一：小型Web应用，日活1万以内，数据库4核8G。这种情况并发不高，连接池设10-15就够了，超时设15秒。核心原则是够用就行，别浪费资源。

场景二：中型电商或SaaS平台，日活10万级，数据库8核16G。连接池建议30-50，超时20秒，同时开启连接有效性检测（validationQuery或connectionTestQuery），确保拿到的连接是活的。

场景三：高并发秒杀或直播系统，瞬间QPS上千。这种场景单靠调大连接数解决不了问题，必须配合读写分离、分库分表、缓存层。连接池可以适当放大到80-100，但更重要的是缩短单个SQL的执行时间，超时设10秒以内快速失败。

四、监控和动态调整才是核心

配置不是一劳永逸的事。上线后必须监控三个指标：连接池活跃连接数、等待获取连接的线程数、连接获取平均耗时。如果活跃连接长期接近最大值，说明该扩容了；如果等待线程频繁出现，说明连接不够用或者有慢SQL在拖后腿。

HikariCP自带JMX监控，可以直接接入Prometheus+Grafana看板。Druid也有内置的监控页面，开启方式：

spring.datasource.druid.stat-view-servlet.enabled=true
spring.datasource.druid.stat-view-servlet.url-pattern=/druid/*

通过监控面板你能看到实时的活跃连接、空闲连接、等待线程、SQL执行统计。这些数据才是你调优的依据，而不是拍脑袋设数字。

五、常见坑和避坑指南

坑一：连接数超过数据库承受能力。MySQL默认max_connections是151，你应用端设了200，结果数据库拒绝连接。解决办法：先查数据库的max_connections，应用端永远不要超过它。

坑二：忘记设置连接有效性检测。连接池里的连接可能已经被数据库端关闭了，但池不知道，拿出来用就报错。HikariCP默认用isValid()检测，Druid需要配置validationQuery：

spring.datasource.druid.validation-query=SELECT 1
spring.datasource.druid.test-while-idle=true
spring.datasource.druid.test-on-borrow=false

坑三：超时设成0或者负数。有些开发者为了"不报错"把超时设成无限等待，结果一个慢SQL卡住，所有请求都堵在那里，系统直接雪崩。超时一定要设，而且要合理。

坑四：只调连接池不优化SQL。连接池配置得再好，如果你的SQL一条跑5秒，连接很快就被占满。优化索引、减少不必要的查询、用批量操作替代循环单条插入，这些才是根本。

六、连接池选型的简要建议

目前主流选择就三个：HikariCP、Druid、C3P0。C3P0已经过时，不推荐。HikariCP性能最好、配置最简洁，适合大多数Java项目。Druid功能更丰富，自带监控和SQL防火墙，适合需要额外管控的场景。如果你用Spring Boot 2.x以上，默认就是HikariCP，直接在application.yml里配就行。

七、总结：一套可执行的配置流程

第一步，确认数据库服务器的max_connections值。第二步，根据并发量和硬件估算应用端连接池大小，取数据库上限的50%-70%。第三步，设置合理的超时参数：connectionTimeout 10-30秒，idleTimeout 5-10分钟，maxLifetime 30分钟。第四步，上线后接入监控，观察一周数据。第五步，根据监控结果微调，每次调整幅度不超过20%。这套流程走下来，你的数据库连接池基本就稳了。

最后说一句大实话：连接池配置是系统工程，不是改一个数字就完事。它跟你的SQL质量、数据库参数、服务器硬件、应用架构都有关系。把每个环节都做好，系统才能真正扛住高并发。