mysql最大连接数需结合历史峰值、服务器资源和应用模式科学设定：先查 Max_used_connections 与 max_connections 比例，再按内存（约 1MB/ 连接）和系统限制反推安全值，配套调整 w ait_timeout、thread_cache_size 等参数，并优先优化应用层连接池与 代码规范。
MySQL 最大连接数不能拍脑袋定，得看实际负载、资源余量和应用模式。默认 151 明显偏低，但盲目调到 5000 也不一定合适——关键在“够用且留有缓冲”，同时避免内存浪费和 线程 争抢。
先看历史峰值再定上限
直接查服务器过去用过多少连接，比凭空估算更可靠：
- 执行 SHOW GLOBAL STATUS LIKE ‘Max_used_connections’; 获取历史最高 并发 连接数
- 再查当前设置：SHOW VARIABLES LIKE ‘max_connections’;
- 算比例：如果 Max_used_connections / max_connections ≈ 80%~85%，说明设置较合理
- 若长期低于 20%，说明上限过高，白白占用内存；若经常接近 100%，就得扩容或优化
按服务器资源反推安全值
每个连接至少消耗 256KB 内存（含排序缓冲、临时表等），高配场景可能达 3~4MB。例如：
- 一台 16GB 内存的服务器，留给 MySQL 约 10GB，按平均 1MB/ 连接算，理论安全上限约 8000～10000
- 但还要预留系统、其他进程、文件描述符（ulimit -n需≥2×max_connections）、线程缓存空间
- 建议起步值设为 500～1000，观察一周后根据 Threads_created 增速和内存使用率微调
必须配套调整的关联参数
只改 max_connections 不调其他，容易引发新问题：
- wait_timeout 和 interactive_timeout：设为 60～300 秒，及时回收空闲 Sleep 连接
- thread_cache_size：设为 Max_used_connections 的 1 /4～1/2（如峰值 800，可设 16～32），减少频繁创建销毁线程开销
- open_files_limit：在 my.cnf 中同步提高，一般设为 max_connections × 2 以上，避免“Too many open files”报错
应用层比 数据库 层更关键
多数连接爆满问题根源不在 MySQL，而在应用没管好连接：
- 务必启用连接池（如 HikariCP、Druid），设置 min-idle=5～10，max-active=50～200，避免连接数随 QPS 线性飙升
- 检查代码是否漏关 Connection/Statement/ResultSet，尤其异常分支
- 禁用长事务和未加 LIMIT 的全表查询，这类操作会锁住连接长达数秒甚至分钟
- 对读多写少业务，优先考虑读写分离，把压力从主库分流
