MySQL连接数超限怎么优化_调整max_connections与wait_timeout

MySQL的max_connections并非越大越好，过高会导致内存溢出和系统文件描述符不足；需根据实际峰值预留20%余量，上限不超max(500, 实际峰值×1.2)，并同步调高系统级open files限制。max_connections设太高反而会压垮服务器MySQL的max_connections不是越大越好。每个连接至少占用数MB内存（线程栈、缓存、临时表等），设成1000却只有2GB内存的机器，可能刚启动就OOM。Linux还可能因ulimit -n限制无法真正打开那么多文件描述符，导致实际可用连接远低于配置值。实操建议：先查真实峰值：SHOW STATUS LIKE 'Threads_connected'; 和历史监控（比如Prometheus+mysqld_exporter）里过去7天最高值预留20%余量，但上限别超max(500, 实际峰值 × 1.2)；小业务100–200足够改完必须重启MySQL或用SET GLOBAL max_connections = N;（注意：动态设置在重启后失效）同步检查系统级限制：cat /proc/$(pidof mysqld)/limits | grep "Max open files"，不够就调/etc/security/limits.confwait_timeout太长会让空闲连接占着茅坑默认8小时的wait_timeout对Web应用极其危险——应用层没及时close，连接就挂着不动，慢慢吃光max_connections。你看到Too many connections错误，大概率不是并发真高，而是几百个“僵尸连接”在睡觉。实操建议：Web应用统一设为60–300秒（5分钟足够处理绝大多数请求+重试）区分场景：应用连接池用wait_timeout，交互式客户端（如mysql命令行）用interactive_timeout，后者可稍长验证是否生效：SHOW VARIABLES LIKE '%timeout%';，再连一个新会话查SELECT @@wait_timeout;Java应用要确认连接池（如HikariCP）的connection-timeout和idle-timeout比MySQL的wait_timeout更短，否则池子自己就卡住连接没释放？先盯紧应用层的close逻辑调低wait_timeout只是兜底，根子在代码。常见错误是try-catch里忘了conn.close()，或者用了Spring @Transactional但没配transactionManager，导致事务不提交、连接不归还。 灵办AI 免费一键快速抠图，支持下载高清图片