MySQL最大连接数需结合历史峰值、服务器资源和应用模式科学设定：先查Max_used_connections与max_connections比例，再按内存（约1MB/连接）和系统限制反推安全值，配套调整wait_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的全表查询，这类操作会锁住连接长达数秒甚至分钟
- 对读多写少业务，优先考虑读写分离，把压力从主库分流
