最大连接数需合理配置，核心是mysql的max_connections与java连接池maximumpoolsize匹配；应依据历史峰值（max_used_connections）和硬件资源（内存、文件描述符等）反推安全上限，并配合超时与验证机制防止连接失效。
最大连接数不是设得越多越好，关键要让数据库能接住、应用不卡死、资源不浪费。核心是让 MySQL 的 max_connections 和 Java 连接池的 maximumPoolSize 互相匹配，而不是各自拍脑袋定值。
先看数据库实际扛过多少连接
别猜，直接查历史峰值：
-
SHOW GLOBAL STATUS LIKE 'Max_used_connections';—— 看过去最高用过多少连接 -
SHOW VARIABLES LIKE 'max_connections';—— 看当前上限设了多少 - 如果前者长期占后者的 70%～85%，说明当前设置比较合理；低于 30% 就偏高，白白占内存；接近或超过 100%，就得立刻扩容或优化
按硬件和业务反推安全上限
每个 MySQL 连接平均吃 1MB 左右内存（含排序缓冲、临时表等），16GB 服务器留给 MySQL 10GB，理论最多撑约 10000 连接，但必须留余量：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 操作系统文件描述符限制：
ulimit -n至少设为max_connections × 2 - 配套调
open_files_limit和thread_cache_size（建议设为峰值连接数的 1/4～1/2） - 起步建议值：500～1000，上线后观察
Threads_created增速和内存使用率再微调
Java 连接池最大值不能只看 QPS
maximumPoolSize 不等于“每秒请求数”，得结合连接持有时间算：
- 例如 QPS=200，平均每个请求占连接 200ms → 理论需 40 个连接（200 × 0.2）
- 再加 50% 缓冲防抖动，设成 60～80 更稳
- 更稳妥的参考上限：
(CPU 核心数 × 2) + 磁盘数，这是数据库能高效处理的并发连接数 - HikariCP 默认
maximumPoolSize=10，生产环境务必改；Druid 建议设 50～200，视业务复杂度而定
超时与验证必须配对生效
光设最大连接数不配超时和校验，等于埋雷：
-
connectionTimeout（获取连接超时）：设 3～30 秒，太短易误抛异常，太长线程卡死 - 必须与 MySQL 的
wait_timeout（默认 8 小时）错开，建议设为其 1/10～1/3（如 300 秒） - 验证方式优先用
isValid()（底层调mysql_ping），比SELECT 1更轻量 - 搭配
idleTimeout（空闲回收）和maxLifetime（最大存活），防止连接被数据库静默断开后失效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
