jdbc连接池需按业务水位分层配置minidle和maxactive：minidle应≥日常平均并发×0.7且≤maxactive的30%～50%，maxactive须≤db max_connections的70%，并配合空闲回收参数防句柄抽搐。
配置 JDBC 连接池的最小空闲数（minIdle）和最大激活数（maxActive 或 maxTotal）不是简单填数字，而是要匹配数据库服务能力与应用并发特征，避免因连接突增/突降引发句柄抖动——即“句柄抽搐”：表现为连接频繁创建销毁、文件句柄瞬时飙升、TIME_WAIT堆积、甚至数据库端报“too many connections”或拒绝新连接。
明确两个参数的真实作用
• minIdle：池中始终保留的、已建立但未被使用的空闲连接数。它决定冷启动响应速度和低峰期资源保有量；设得太低，突发请求需临时建连，延迟高且易触发句柄激增；设得太高，空闲连接长期占用数据库侧句柄，浪费资源。
• maxActive / maxTotal：池允许同时存在的最大连接总数（含活跃+空闲）。它是一道硬闸门，超过则线程阻塞或抛异常。若设得远超数据库实际处理能力（如 MySQL 默认 max_connections=151），会直接压垮 DB 服务端，引发句柄雪崩。
防抽搐的关键配比逻辑
不靠经验拍脑袋，而按业务水位分层控制：
一款AI开发辅助工具，主要用于从 AI 编程会话日志（Clawdbot、Claude Code、Codex）中提取对话记录。该功能用于在用户要求导出提示词历史、会话日志或 `.jsonl` 格式的会话文件时使用，适合需要提升相关任务效率的用户。
- 基础守门值：minIdle 应 ≥ 应用日常平均并发请求数 × 0.7（留冗余），且 ≤ maxActive 的 30%～50%。例如日均 QPS 200、平均 RT 80ms，则平均并发 ≈ 16，建议 minIdle = 8～12。
-
峰值天花板：maxActive 必须 ≤ 数据库
max_connections的 70%，并预留至少 20% 给后台任务、监控、管理连接。若 DB 设置为 200，则 maxActive 不宜超过 140。 -
空闲回收节奏：配合
minEvictableIdleTimeMillis（如 300000ms）和timeBetweenEvictionRunsMillis（如 30000ms），让空闲连接在低谷期平稳释放，而非堆满后集中 GC 式销毁。
典型场景参考值（MySQL + Druid/HikariCP）
• 中小业务（QPS ≤ 300，DB max_connections=300）：
minIdle = 10，maxActive = 80，maxWait = 3000
• 高并发服务（QPS 1000+，DB 已调至 max_connections=1000）：
minIdle = 30，maxActive = 600，minEvictableIdleTimeMillis = 600000
• Hyperion Planning 类 OLAP 应用（用户登录密集型）：
JDBC_MIN_CONNECTIONS = 10，JDBC_MAX_CONNECTIONS = 45（Oracle 官方推荐，兼顾登录潮与复用率）
必须避开的抽搐陷阱
• minIdle > maxActive：配置矛盾，多数连接池会自动修正或启动失败；
• maxActive 设为 -1 或 Integer.MAX_VALUE：等于放弃保护，DB 句柄数随流量直线冲顶；
• 忽略数据库侧限制：只调大连接池，却不调 DB 的 max_connections、open_files_limit，必然触发 OS 层句柄耗尽；
• testOnBorrow = true + validateQuery 耗时高：每次借连接都执行 SELECT 1，放大延迟，诱发排队和连接超时重试风暴。
