MySQL + HikariCP 连接数调优实战：如何查看用量 & 合理配置 max_connections
在做 Java 后端开发时，我们经常会遇到 MySQL 连接数配置问题，比如：
max_connections配多少合适？- HikariCP 的
maximum-pool-size要不要调？ - 怎么知道现在数据库的连接用量？
本文结合实战，总结了查看方法、计算方式和调优建议。
1. 查看当前连接使用情况
1.1 查看总连接数 & 活跃连接数
SHOW STATUS LIKE 'Threads_connected'; -- 当前总连接数（包括空闲）
SHOW STATUS LIKE 'Threads_running'; -- 当前活跃连接数（正在执行 SQL）
示例输出：
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_connected | 74 |
| Threads_running | 1 |
+-------------------+-------+
- Threads_connected=74 → 现在总共有 74 条连接（大部分可能空闲）
- Threads_running=1 → 只有 1 条连接在执行 SQL
1.2 持续监控连接变化（高峰期更有参考价值）
Linux 下可以用 watch 命令：
watch -n 1 "mysql -u用户名 -p密码 -e \"SHOW STATUS LIKE 'Threads_connected'; SHOW STATUS LIKE 'Threads_running';\""
每秒刷新一次，让你看到高峰期连接数变化。
1.3 查看每个连接的详细信息
SHOW FULL PROCESSLIST;
常用字段：
- User：哪个用户
- Host：从哪台服务器连过来
- Command：执行状态（Sleep = 空闲）
- Time：执行/空闲的时间（秒）
1.4 查看 MySQL 最大连接限制
SHOW VARIABLES LIKE 'max_connections';
2. max_connections 配多少合适？
2.1 计算公式
建议：
max_connections ≥ （所有应用连接池最大值之和）× 1.2
- 所有应用连接池最大值 = 多个服务的
maximum-pool-size之和 - 1.2 是预留 20% 的余量，防止偶发的瞬时连接高峰
2.2 实战示例
假设：
- 只有一个 Java 应用
- HikariCP 配置：
maximum-pool-size=100
那么：
max_connections = 100 × 1.2 = 120
为了保险，可以设 150~200。
2.3 配置方法
临时生效（重启失效）：
SET GLOBAL max_connections = 200;
永久生效（修改 my.cnf / my.ini）：
[mysqld]
max_connections = 200
3. HikariCP 参数调优建议
假设你的 Spring Boot 配置如下：
spring:datasource:hikari:maximum-pool-size: 100 # 最大连接数minimum-idle: 20 # 最小空闲连接数max-lifetime: 1800000 # 连接最大存活时间（ms）connection-test-query: SELECT 1
3.1 maximum-pool-size
- 最大连接数，建议略小于
max_connections（留给其他系统一些空间） - 如果高峰期
Threads_running只有 20，没必要配 100，可以改成 30 左右
3.2 minimum-idle
- 最小空闲连接数，建议设置为 常态并发数，避免过多空闲连接浪费资源
3.3 max-lifetime
- 连接最大存活时间，建议略小于数据库
wait_timeout - MySQL 默认
wait_timeout= 8 小时，可以配 30 分钟或 1 小时
3.4 connection-test-query
- 如果数据库支持 JDBC4 ping（MySQL 支持），可以不配，Hikari 会自动调用
isValid()更高效
4. 调优流程总结
- 监控高峰期连接数（
Threads_running） - 计算 max_connections = 高峰连接池总和 × 1.2
- 设置 maximum-pool-size ≈ 高峰活跃数 × 1.2
- 合理配置 minimum-idle（接近常态并发）
- 调整 max-lifetime（小于数据库
wait_timeout） - 压测验证，确保无
Too many connections报错
5. 小结
max_connections不是越大越好，要根据业务并发量 + 连接池配置来定- 连接池最大值 也要结合实际活跃数，不要盲目调大
- 观察高峰期数据比拍脑袋设参数更靠谱
建议你在业务高峰时用 watch 连续观察 5~10 分钟，把最大 Threads_running 记录下来，再去定参数，这样 MySQL 和 HikariCP 都不会浪费资源，也能稳定运行。
