最大连接数需三方对齐：先查MySQL实际负载（Max_used_connections和max_connections），再按QPS×平均持有时间×1.5估算应用需求，最后设maximumPoolSize≤数据库max_connections的70%，并调优超时参数。
最大连接数不是越大越好，关键要让应用、连接池和数据库三方能力对齐。设高了压垮数据库，设低了卡住业务，合理值得算出来，不是拍脑袋。
先看数据库能扛多少
别凭感觉，直接查 MySQL 实际负载：
- SHOW GLOBAL STATUS LIKE 'Max_used_connections'; —— 看历史峰值用过多少连接
- SHOW VARIABLES LIKE 'max_connections'; —— 看当前上限是多少
如果峰值长期占上限的 70%～85%，说明当前设置较合理；低于 30% 就偏高，浪费内存；接近或超过 100%，必须扩容或优化 SQL。
每条 MySQL 连接平均消耗约 1MB 内存（含排序缓冲、临时表等），16GB 服务器给 MySQL 分 10GB，理论最多撑约 10000 连接，但要留至少 20% 余量——操作系统文件描述符（ulimit -n）也得同步调高，建议设为 max_connections × 2。
再算应用真正需要多少
maximumPoolSize ≠ QPS，得结合连接持有时间估算：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 例如：QPS = 200，平均每个请求占连接 200ms → 理论需 40 个连接（200 × 0.2）
- 再加 50% 缓冲防抖动，建议设为 60～80
更稳妥的经验上限是：CPU 核心数 × 2 ～ 6（I/O 密集型可取高值），但必须经 JMeter 或 wrk 压测验证——观察连接获取耗时、DB CPU 使用率、Threads_created 增速，找到“等待时间开始明显上升”的拐点。
最后匹配连接池与数据库限制
Java 连接池的 maximumPoolSize 应 ≤ 数据库 max_connections 的 70%，为后台任务、监控、管理连接留出空间。
- HikariCP 默认是 10，生产环境必须改
- Druid 建议 50～200，视 SQL 复杂度和远程调用比例调整
- 避免设成 32767 这类理论最大值，实际极少需要
同时配好超时参数：connectionTimeout 建议 10～30 秒，idleTimeout（10 分钟）必须小于 maxLifetime（30～90 分钟），防止连接被 MySQL wait_timeout 静默断开后归还失败。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
