盲目调大max_connections会拖慢响应，因其增加内存占用、线程切换与锁竞争；真正瓶颈常是wait_timeout过大导致的Sleep僵尸连接，应优先调小wait_timeout并检查Threads_connected与SHOW PROCESSLIST定位问题。
直接改 max_connections 会让响应更慢，而不是更快
盲目调大 max_connections 是最常见误区。每个连接默认占 256KB–1MB 内存（含线程栈、会话缓存等），设成 1000 就多吃掉近 1GB 常驻内存；高并发下线程上下文切换、锁竞争、查询排队开销会陡增，反而拖垮响应。你看到“响应慢”，大概率是几百个 Sleep 连接挂着不走，不是真缺连接数。
先确认是不是真爆满：用三句 SQL 定位问题根源
别只看报错，执行这三条命令才能判断真实状况：
-
SHOW VARIABLES LIKE 'max_connections';—— 看上限（默认常为 151） -
SHOW STATUS LIKE 'Threads_connected';—— 看当前活连接数，接近上限才是真爆满 -
SHOW PROCESSLIST;—— 重点筛State = 'Sleep'且Time > 300的行，这些就是“僵尸连接”
如果 Threads_connected 远低于 max_connections，但响应慢，说明是空闲连接堆积 + 查询排队，不是连接数不够。
wait_timeout 比 max_connections 更关键
大量 Sleep 连接的根源，往往是 wait_timeout 设得太大（默认 28800 秒 = 8 小时）。应用没关连接，MySQL 就一直留着，直到超时才释放——这期间它既不干活，又占线程和内存。
- Web 应用建议设为
60–300（秒），足够处理请求+重试 - 动态生效：
SET GLOBAL wait_timeout = 60;+SET GLOBAL interactive_timeout = 60; - 永久生效：在
/etc/my.cnf的[mysqld]段加这两行，再重启 - 注意：
wait_timeout不影响正在执行的查询，只管空闲连接
真要调 max_connections，必须同步处理三个硬限制
只改 max_connections 几乎一定失败，因为操作系统和 MySQL 自身会卡住：
-
ulimit -n（文件描述符限制）：Linux 默认常为 1024，若设max_connections = 2000，MySQL 启动直接报Can't create thread (errno: 24) - 内存：每增 1 连接 ≈ 多占 256KB，1000 连接 ≈ 256MB 额外常驻内存
- 管理通道：MySQL 8.0+ 必须启用
admin_port，否则连接爆满时连管理员都进不去——加admin_address=127.0.0.1和admin_port=33062到配置文件并重启
最常被忽略的是：应用层连接池（如 HikariCP）的 maximumPoolSize 必须小于 MySQL 的 max_connections，否则池子抢光所有连接，其他服务直接连不上。
