Spring Boot整合Druid连接池配置失效的五大原因与排查指南

1. 问题引入：一个看似简单的配置为何会“失灵”？

最近在整合一个Spring Boot项目，准备接入Druid数据库连接池。这本来应该是个常规操作，按照官方文档或者网上的教程，在application.yml里加上几行配置，启动项目，一切就应该水到渠成。但现实往往喜欢开个小玩笑，我按照最标准的步骤配置了Druid，启动日志里也看到了DruidDataSource初始化的信息，满心以为大功告成。然而，当我打开Druid内置的监控页面/druid/index.html时，却提示404。更关键的是，通过日志观察或者连接数据库测试，发现连接池的参数，比如初始连接数、最大连接数、监控统计开关等，似乎并没有按照我配置文件里的值生效。这感觉就像你给一台机器输入了指令，它点头说“收到”，但实际干的却是另一套。

这个问题其实挺典型的，尤其在Spring Boot这种“约定大于配置”的框架里。它帮你自动装配了很多东西，省去了大量繁琐的XML配置，但有时候，这种“智能”也会带来一些隐蔽的坑。你以为配置生效了，实际上Spring Boot可能用了另一套默认的逻辑，或者你的配置因为优先级、拼写、依赖缺失等问题，被静默忽略了。这不只是Druid的问题，很多其他组件的集成，比如Redis、RabbitMQ等，都可能遇到类似的“配置不生效”的困境。今天，我就结合这次踩坑经历，把Spring Boot中配置Druid数据源不生效的几种常见原因和排查思路，从头到尾捋一遍。无论你是刚接触Spring Boot的新手，还是有一定经验但被类似问题困扰的开发者，相信这篇详细的排查指南都能帮你节省不少时间。

2. 基础环境搭建与标准配置流程复盘

在开始排查问题之前，我们有必要先确认一下最基础的、理论上应该能工作的配置流程是怎样的。这能帮助我们建立一个正确的“基准”，后续的排查都是基于这个基准进行的偏差修正。

首先，项目的依赖必须正确。对于Spring Boot 2.x及以上版本，我们通常不直接引入Druid的原始依赖，而是使用阿里巴巴提供的druid-spring-boot-starter。这个starter封装了与Spring Boot自动配置的集成，会省事很多。在你的pom.xml文件中，应该有这样一段依赖声明：

<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.16</version> <!-- 请使用当前最新稳定版本 --> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>

这里有一个关键点：务必使用druid-spring-boot-starter，而不是普通的druid。普通druid依赖只是一个纯粹的连接池实现，不包含与Spring Boot配置属性绑定的自动化配置类（DruidDataSourceAutoConfigure）。少了这个自动配置类，Spring Boot就无法识别application.yml中以spring.datasource.druid为前缀的配置项，你的所有配置自然就失效了。

依赖搞定后，接下来就是配置文件。以YAML格式的application.yml为例，一个功能相对完整的Druid配置通常长这样：

spring: datasource: # 1. 基础数据源配置 (Spring Boot标准属性) driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/your_database?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password # 2. 指定使用Druid数据源 (关键！) type: com.alibaba.druid.pool.DruidDataSource # 3. Druid连接池专属配置 druid: # 连接池核心参数 initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false # 监控统计相关配置 web-stat-filter: enabled: true url-pattern: /* exclusions: "*.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/*" stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin login-password: admin123 reset-enable: false filter: stat: enabled: true log-slow-sql: true slow-sql-millis: 2000 wall: enabled: true config: enabled: true

这份配置可以分为三个逻辑部分。第一部分是JDBC标准配置，告诉Spring Boot如何连接到数据库。第二部分type: com.alibaba.druid.pool.DruidDataSource至关重要，它明确指示Spring Boot使用Druid作为数据源实现。如果没有这一行，Spring Boot会根据classpath下的依赖自动选择，通常是HikariCP（如果存在）。如果同时存在HikariCP和Druid，且未指定type，Spring Boot 2.x默认会优先选择HikariCP，导致Druid配置无效。第三部分是以spring.datasource.druid开头的Druid专属配置，用于细粒度控制连接池行为和开启监控。

理论上，完成以上两步后启动应用，你应该能在启动日志中看到类似DruidDataSource初始化成功的字样，并且能够通过http://localhost:8080/druid/index.html访问监控登录页（如果配置了stat-view-servlet.enabled=true）。如果没达到这个效果，那么我们就需要进入排查环节了。

3. 配置不生效的五大常见根因与深度排查

当标准流程走不通时，问题往往出在细节上。下面我梳理了五种最常见导致Druid配置“失灵”的情况，并提供了详细的排查方法和解决方案。

3.1 依赖冲突与自动配置的“静默失败”

这是最隐蔽也最常见的问题之一。Spring Boot的自动配置（Auto-Configuration）是其核心魅力，但也可能成为问题的源头。

问题现象：你的配置看起来完全正确，但Druid的连接池参数（如max-active）依然是默认值，监控页面也无法访问。查看启动日志，甚至可能看不到DruidDataSource相关的初始化日志，或者看到的是HikariCP的初始化日志。

根因分析：

1. 未使用Starter：如前所述，使用了普通的druid依赖而非druid-spring-boot-starter。
2. 多数据源类型共存：你的项目中可能无意间引入了HikariCP的依赖（例如，通过spring-boot-starter-jdbc或spring-boot-starter-data-jpa，它们默认传递依赖HikariCP）。当spring.datasource.type未明确指定时，Spring Boot的DataSourceAutoConfiguration会按照一定顺序（通常是Hikari -> Tomcat -> DBCP2 -> Druid）自动选择数据源。HikariCP优先级高于Druid，因此被选中。
3. 自动配置被排除或条件不满足：DruidDataSourceAutoConfigure类可能因为某些条件（@ConditionalOnClass,@ConditionalOnProperty）不满足而被跳过。

排查步骤与解决方案：

1. 检查依赖树：在项目根目录执行mvn dependency:tree命令，搜索druid和hikari。确保druid-spring-boot-starter存在，并且没有其他数据源实现被优先引入。如果存在HikariCP，而你又确定只用Druid，可以在spring-boot-starter-jdbc中排除它：

   <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> <exclusions> <exclusion> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId> </exclusion> </exclusions> </dependency>

2. 显式指定type：无论如何，在配置文件中明确写上spring.datasource.type: com.alibaba.druid.pool.DruidDataSource是最佳实践，这能消除自动选择带来的不确定性。
3. 查看自动配置报告：在application.yml中开启调试模式：debug: true。启动应用后，控制台会打印一份详细的自动配置报告。搜索“DruidDataSourceAutoConfiguration”，查看它是否被启用（Matched）或跳过（Did not match）。如果被跳过，报告会给出原因，比如@ConditionalOnClass缺少某个类，这是排查依赖问题的黄金信息。
4. 检查启动类注解：确保你的主启动类上没有使用@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})来排除数据源自动配置。如果排除了，Druid的自动配置自然也不会生效。

3.2 配置属性名错误与YAML格式陷阱

Spring Boot使用宽松的绑定规则，比如maxActive、max-active、max_active在配置文件中通常可以互换。但Druid Starter对某些属性的绑定可能有特定要求，或者YAML的缩进格式容易写错。

问题现象：部分配置生效（如基础URL），但部分Druid专属配置（如监控页面、过滤器）不生效。

根因分析：

1. 属性前缀错误：Druid专属配置必须放在spring.datasource.druid之下。如果你错误地写在了spring.datasource同级，或者拼写错误（如druid写成durid），这些配置就不会被DruidDataSourceAutoConfigure处理。
2. 属性名不匹配：虽然Spring Boot支持宽松绑定，但最好遵循Starter文档中给出的属性名。例如，Druid官方文档可能用maxActive，但在application.yml中使用max-active是更符合Spring Boot习惯的。然而，某些更复杂的嵌套属性，如过滤器配置，必须严格按照Starter定义的属性名来。
3. YAML缩进错误：YAML严格依赖缩进来表示层级关系。如果druid:下面的属性缩进不对（比如用了Tab键，或者空格数不一致），整个druid配置块都可能被解析错误或忽略。

排查步骤与解决方案：

1. 使用IDE的配置提示：现代IDE（如IntelliJ IDEA）对application.yml有很好的支持。当你输入spring.datasource.druid.后，IDE应该能给出属性补全提示。如果没有提示，那很可能意味着你的依赖或配置前缀有问题。
2. 打印生效的配置：在application.yml中增加配置logging.level.org.springframework.boot.autoconfigure.jdbc.DataSourceProperties: DEBUG。启动时，Spring Boot会打印出它从配置文件中加载并绑定到DataSourceProperties对象的所有属性值。通过这个日志，你可以清晰地看到spring.datasource.druid下的各个属性是否被正确读取。
3. 简化配置，逐一验证：先注释掉所有Druid高级配置，只保留type、url、username、password和druid:这个空块。启动成功后再逐一添加initial-size、max-active等配置，每加一个就重启验证一次，可以快速定位是哪个属性名写错了。
4. 核对官方文档：去GitHub上查看druid-spring-boot-starter项目的README或Wiki，里面通常会有一份完整的配置属性列表。这是最权威的参考。

3.3 监控功能（StatViewServlet、WebStatFilter）的特殊配置要求

监控页面（/druid/*）和Web统计过滤器是Druid的特色功能，但它们需要Servlet容器的支持，其配置方式与普通的连接池参数略有不同。

问题现象：数据源连接池本身工作正常（可以连数据库），但监控页面404，或者Web请求的SQL监控统计看不到数据。

根因分析：

1. Servlet配置未生效：stat-view-servlet和web-stat-filter的配置，最终是通过DruidStatViewServletConfiguration和DruidWebStatFilterConfiguration这两个自动配置类，向Servlet容器（Tomcat、Jetty等）注册相应的Servlet和Filter。如果这些自动配置类因为条件不满足（比如缺少Servlet API相关类）而被跳过，监控功能就会失效。
2. 路径冲突或被拦截：/druid/*路径可能被你项目中的其他拦截器（如Spring Security）、过滤器或自定义的Controller映射给覆盖或拦截了。
3. Filter顺序问题：WebStatFilter需要被正确添加到过滤器链中，并且其url-pattern要能覆盖到你想要监控的请求。

排查步骤与解决方案：

1. 确认Starter版本与Servlet环境：确保你使用的是较新版本的druid-spring-boot-starter（如1.2.6+），它对于Spring Boot 2.x的兼容性更好。同时，一个标准的Spring Boot Web项目（依赖了spring-boot-starter-web）肯定会提供Servlet环境，这一点通常没问题。
2. 检查自动配置报告：同样使用debug: true，查看DruidStatViewServletConfiguration和DruidWebStatFilterConfiguration是否被Matched。
3. 检查Security配置：如果你使用了Spring Security，默认会拦截所有请求。你需要放行/druid/*路径。在Security配置类中增加如下规则：

   @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/druid/**").permitAll() // 放行Druid监控所有路径 .anyRequest().authenticated() .and().formLogin(); }

4. 手动注册（备用方案）：如果自动配置始终不生效，可以作为诊断手段或最终方案，手动在配置类中注册Servlet和Filter：

   @Configuration public class DruidConfig { @Bean public ServletRegistrationBean<StatViewServlet> druidServlet() { ServletRegistrationBean<StatViewServlet> reg = new ServletRegistrationBean<>(); reg.setServlet(new StatViewServlet()); reg.addUrlMappings("/druid/*"); reg.addInitParameter("loginUsername", "admin"); reg.addInitParameter("loginPassword", "admin123"); return reg; } @Bean public FilterRegistrationBean<WebStatFilter> druidFilter() { FilterRegistrationBean<WebStatFilter> reg = new FilterRegistrationBean<>(); reg.setFilter(new WebStatFilter()); reg.addUrlPatterns("/*"); reg.addInitParameter("exclusions", "*.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/*"); return reg; } }

   如果手动注册后监控页面可以访问，说明自动配置环节出了问题，可以对比手动配置和自动配置的参数差异来定位原因。

3.4 多数据源场景下的配置混淆

当你的项目需要连接多个数据库时，Druid的配置方式会发生根本性变化。此时，再使用spring.datasource下的单一配置是行不通的。

问题现象：配置了多个数据源，但启动报错，或者只有默认数据源生效，其他数据源的Druid配置无效。

根因分析：Spring Boot的自动配置是为单数据源设计的。当检测到存在多个DataSource类型的Bean时，DataSourceAutoConfiguration会退出，不再提供自动配置。你需要完全手动定义和配置每一个DruidDataSourceBean。

排查步骤与解决方案：

1. 放弃application.yml中的统一配置：在多数据源场景下，spring.datasource开头的配置通常只用于默认数据源，或者完全不用。更常见的做法是将每个数据源的配置定义在自定义的@ConfigurationProperties前缀下，例如spring.datasource.db1,spring.datasource.db2。
2. 手动创建DataSource Bean：你需要在一个配置类中，手动创建多个DataSourceBean。以下是典型示例：

   @Configuration public class MultiDataSourceConfig { // 主数据源配置绑定 @ConfigurationProperties(prefix = "spring.datasource.master") @Bean @Primary // 指定主数据源 public DataSource masterDataSource() { // DruidDataSourceAutoConfigure会基于`spring.datasource.master`前缀的属性创建DataSource // 但为了更清晰的控制，也可以直接new DruidDataSource()并手动set属性 return DruidDataSourceBuilder.create().build(); } // 从数据源配置绑定 @ConfigurationProperties(prefix = "spring.datasource.slave") @Bean public DataSource slaveDataSource() { return DruidDataSourceBuilder.create().build(); } }

   对应的application.yml配置：

   spring: datasource: master: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/master_db username: root password: 123456 type: com.alibaba.druid.pool.DruidDataSource druid: initial-size: 5 max-active: 20 # ... 其他Druid配置 slave: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3307/slave_db username: root password: 123456 type: com.alibaba.druid.pool.DruidDataSource druid: initial-size: 3 max-active: 10 # ... 其他Druid配置

   注意，这里每个数据源都需要明确指定type，并且Druid配置嵌套在各自的druid节点下。
3. 处理监控Servlet/Filter：在多数据源下，监控页面通常只需要一个。Druid Starter的自动配置可能因为检测到多个DataSource而失效。稳妥的做法是参考上一点中的“手动注册”方式，显式地注册一个StatViewServlet和WebStatFilter，它们会监控所有由Druid创建的数据源。

3.5 自定义配置类与自动配置的优先级冲突

有时开发者会出于自定义需求（比如设置连接属性、加密密码等）编写一个@Bean方法来创建DataSource。如果这个方法处理不当，会完全覆盖掉Druid Starter的自动配置。

问题现象：你写了一个@Bean方法返回DataSource，但方法里可能直接new了一个DataSource（无论是DruidDataSource还是其他实现），并且没有将配置文件中的属性注入进去。

根因分析：在Spring中，用户自定义的@Bean定义优先级高于框架的自动配置。如果你手动创建了一个DataSourceBean，那么DruidDataSourceAutoConfigure就不会再触发。如果你在这个手动创建的过程中，没有把application.yml里spring.datasource.druid下的属性应用进去，那么这些配置当然就失效了。

排查步骤与解决方案：

1. 检查是否有自定义DataSource Bean：全局搜索你的项目代码，看是否存在被@Bean注解修饰的、返回类型为DataSource或DruidDataSource的方法。
2. 使用DruidDataSourceBuilder：如果你确实需要自定义一些逻辑，建议使用DruidDataSourceBuilder来创建Bean，它会自动绑定spring.datasource前缀的配置，并允许你进行链式调用覆盖。

   @Bean @ConfigurationProperties(prefix = "spring.datasource") public DataSource dataSource() { // 此方法会读取`spring.datasource`下的所有属性（包括druid子属性）来构建DataSource return DruidDataSourceBuilder.create().build(); }

   确保@ConfigurationProperties注解的prefix正确，并且这个方法所在的配置类没有被@SpringBootApplication排除扫描。
3. 避免完全手动new：尽量不要直接new DruidDataSource()然后一个个setXXX()，除非你有非常特殊的理由。这样做极易遗漏配置，且无法享受Spring Boot配置文件的灵活性和外部化配置的好处。

4. 系统化诊断工具与验证手段

当问题比较复杂，通过以上常见原因无法快速定位时，我们需要借助更系统化的工具和验证手段来洞察Spring Boot应用内部的状态。

4.1 利用Actuator端点透视数据源状态

Spring Boot Actuator提供了丰富的应用监控端点，其中/actuator/health和/actuator/info可能包含数据源信息，但更强大的是/actuator/beans和/actuator/env端点。

操作步骤：

1. 引入Actuator依赖：在pom.xml中添加spring-boot-starter-actuator。
2. 暴露端点：在application.yml中配置暴露所有端点（生产环境请谨慎）或至少暴露beans和env。

   management: endpoints: web: exposure: include: "*" # 或 "beans,env,health"

3. 访问端点分析：
   • /actuator/env：搜索spring.datasource，查看所有相关的配置属性是否被正确加载，以及它们的最终来源（是来自application.yml，还是被其他配置覆盖了）。这是验证配置加载的终极手段。
   • /actuator/beans：搜索dataSource，查看容器中存在的DataSourceBean的具体类型是什么？是DruidDataSource还是HikariDataSource？它的属性值（如maxActive）是多少？这能直接确认生效的数据源实例和其参数。

4.2 日志分析与启动过程追踪

日志是排查问题的第一手资料。除了之前提到的开启debug: true和特定类的DEBUG日志，还可以关注以下几点：

1. 启动日志关键词：在应用启动日志中搜索以下关键词：
   • DruidDataSource：看是否有初始化成功的日志。
   • HikariPool：如果出现这个，说明默认使用了HikariCP。
   • DataSourceAutoConfiguration：看其是否被启用。
   • DruidDataSourceAutoConfigure：看其是否被匹配。
2. 连接池参数日志：Druid在初始化时会打印一行日志，类似{dataSource-1} inited。虽然这行日志不显示具体参数，但你可以通过自定义一个Bean后置处理器，在DataSource初始化后打印其属性来验证：

   @Slf4j @Component public class DataSourceLogger implements BeanPostProcessor { @Override public Object postProcessAfterInitialization(Object bean, String beanName) { if (bean instanceof DruidDataSource) { DruidDataSource ds = (DruidDataSource) bean; log.info("DruidDataSource '{}' initialized with: url={}, maxActive={}, initialSize={}", beanName, ds.getUrl(), ds.getMaxActive(), ds.getInitialSize()); } return bean; } }

4.3 编写简易测试接口进行功能验证

有时候，监控页面问题可能源于网络或前端，而连接池参数问题则需要通过实际使用来验证。编写一个简单的测试接口可以快速确认数据源是否真的在工作。

@RestController @RequestMapping("/test") public class DataSourceTestController { @Autowired private DataSource dataSource; @GetMapping("/ds") public String checkDataSource() throws SQLException { StringBuilder sb = new StringBuilder(); sb.append("DataSource Class: ").append(dataSource.getClass().getName()).append("<br/>"); if (dataSource instanceof DruidDataSource) { DruidDataSource druidDs = (DruidDataSource) dataSource; sb.append("=== Druid Pool Status ===<br/>"); sb.append("URL: ").append(druidDs.getUrl()).append("<br/>"); sb.append("ActiveCount: ").append(druidDs.getActiveCount()).append("<br/>"); sb.append("PoolingCount: ").append(druidDs.getPoolingCount()).append("<br/>"); sb.append("MaxActive: ").append(druidDs.getMaxActive()).append("<br/>"); sb.append("InitialSize: ").append(druidDs.getInitialSize()).append("<br/>"); // 尝试获取一个连接 try (Connection conn = druidDs.getConnection()) { sb.append("Connection Test: SUCCESS<br/>"); } } else { sb.append("Not a DruidDataSource!<br/>"); } return sb.toString(); } }

访问这个接口，你可以直接看到当前数据源的类型、关键参数以及连接测试结果，这是最直接的验证方式。

5. 从问题到预防：最佳实践与配置模板

经过一番排查和修复，问题终于解决了。但更重要的是，如何避免下次再踩进同一个坑？根据我的经验，遵循以下最佳实践可以极大降低配置不生效的概率。

1. 依赖管理标准化：

• 统一使用druid-spring-boot-starter。
• 在父POM或依赖管理部分，明确定义Druid Starter的版本，避免不同模块版本冲突。
• 如果确定不使用HikariCP，在引入spring-boot-starter-jdbc或相关数据库starter时，将其排除。

2. 配置清晰化与显式声明：

• 必须在application.yml中明确指定：spring.datasource.type: com.alibaba.druid.pool.DruidDataSource。
• 使用IDE的配置提示功能编写druid下的属性，避免拼写错误。
• 对于YAML，使用统一的缩进风格（建议2个空格），并利用IDE的格式化功能（Ctrl+Alt+L）。
• 将Druid配置单独提取到一个druid:块内，与基础JDBC配置区分开，结构清晰。

3. 多环境配置策略：

• 监控页面的登录密码等敏感信息，不要硬编码在application.yml中。应使用application-{profile}.yml区分环境，或将密码放在环境变量、配置中心。
• 在生产环境，可以考虑将stat-view-servlet.enabled设置为false，或通过防火墙/安全组严格限制/druid/*路径的访问IP。

4. 推荐的基础配置模板： 下面是一个我经过多个项目验证、比较稳定的Druid基础配置模板，涵盖了连接池、监控和防御性编程常用设置：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/db_example?useUnicode=true&characterEncoding=UTF-8&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai username: your_username password: your_password type: com.alibaba.druid.pool.DruidDataSource # 关键！ druid: # 连接池核心参数 initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 # 获取连接超时时间(ms) time-between-eviction-runs-millis: 60000 # 检测间隔 min-evictable-idle-time-millis: 300000 # 最小空闲存活时间 validation-query: SELECT 1 test-while-idle: true # 空闲时检测 test-on-borrow: false # 借出时不检测，性能更好 test-on-return: false # 归还时不检测 # 连接泄露检测 (强烈建议开启) remove-abandoned: true remove-abandoned-timeout: 1800 # 30分钟 log-abandoned: true # 监控统计 web-stat-filter: enabled: true url-pattern: /* exclusions: "*.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/*" stat-view-servlet: enabled: true # 生产环境建议关闭或加访问限制 url-pattern: /druid/* login-username: admin login-password: ${DRUID_ADMIN_PASSWORD:admin123} # 从环境变量读取，默认admin123 reset-enable: false # 禁用重置按钮 allow: 127.0.0.1 # 可选，设置白名单IP，生产环境用 deny: # 可选，设置黑名单IP # 过滤器配置 (stat用于监控，wall用于防御SQL注入，config用于密码加密等) filter: stat: enabled: true log-slow-sql: true slow-sql-millis: 2000 merge-sql: true # 合并相似SQL wall: enabled: true config: drop-table-allow: false # 禁止删表 config: enabled: true # 启用配置过滤器，用于连接属性解密等

这个模板提供了一个兼顾性能、稳定性和可观测性的起点。其中，连接泄露检测（remove-abandoned）和SQL防火墙（wall）对于线上系统尤为重要，可以在早期发现代码中未正确关闭连接的问题和潜在的SQL注入风险。记住，配置不是一成不变的，需要根据实际应用的数据库负载、硬件资源和业务特点进行调整，例如max-active、max-wait等参数。