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的全表查询，这类操作会锁住连接长达数秒甚至分钟 对读多写少业务，优先考虑读写分离，把压力从主库分流
