minIdle是连接池运行时配置项，非JVM环境变量，须通过application.yml或server.xml的<Resource>设置；HikariCP用minimum-idle，Tomcat JDBC Pool用minIdle，二者语义相同，均控制池中最小空闲连接数。
Tomcat连接池的minIdle不是环境变量，而是连接池实现自身的配置项
很多人搜“最小空闲数 环境变量”，结果配了半天JAVA_OPTS或CATALINA_OPTS都没生效——因为minIdle根本不在JVM启动参数里。它属于连接池（如HikariCP、Tomcat JDBC Pool）的运行时配置，必须通过应用配置文件（如application.yml）或数据源定义（如server.xml中<Resource>）设置。
minIdle在HikariCP和Tomcat JDBC Pool中的位置差异
Spring Boot默认用HikariCP，而原生Tomcat服务器内置的是Tomcat JDBC Pool，两者参数名不同但语义一致：
- HikariCP用
minimum-idle（注意是短横线，不是下划线） - Tomcat JDBC Pool用
minIdle（驼峰或全小写均可，XML中常写作minIdle） - 两者都控制“池中始终保留的空闲连接数”，低于该值时连接池会主动创建新连接补足
示例（HikariCP，application.yml）：
spring:
datasource:
hikari:
minimum-idle: 10
maximum-pool-size: 50示例（Tomcat JDBC Pool，server.xml）：
<Resource name="jdbc/mydb"
auth="Container"
type="javax.sql.DataSource"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
minIdle="10"
maxActive="50"
... />为什么硬塞进环境变量会失效？
环境变量只能影响JVM启动参数或Tomcat容器级行为（如maxThreads），无法穿透到HikariCP或Tomcat JDBC Pool的内部属性。常见踩坑点包括：
- 在
JAVA_OPTS里写-Dhikari.minimum-idle=10→ HikariCP不读系统属性，忽略 - 在
setenv.sh里导出MIN_IDLE=10→ 没有代码去读这个变量，白搭 - 把
minIdle当Tomcat全局参数写进server.xml的<Connector>节点 → 这是HTTP连接器配置，跟数据库池无关
真正需要协调的超时参数链
minIdle单独调高没用，必须和几个关键超时配合，否则空闲连接会被误杀：
-
idle-timeout（HikariCP）或minEvictableIdleTimeMillis（Tomcat JDBC Pool）：空闲多久才允许回收；若它比minIdle的维持逻辑更激进，连接刚建好就被干掉 -
max-lifetime：连接最大存活时间，必须显著大于idle-timeout，否则健康连接被提前淘汰 -
connection-timeout：获取连接的等待上限，若minIdle太低+并发突增，大量请求会卡在这里超时
典型安全组合（HikariCP）：
minimum-idle: 10 idle-timeout: 600000 # 10分钟 max-lifetime: 1800000 # 30分钟，> idle-timeout
记住：minIdle不是越大越好——它意味着常驻内存的连接数，每个连接都占数据库侧一个会话资源。MySQL默认max_connections=151，设minimum-idle: 50就直接吃掉三分之一。
