MySQL的max_connections并非越大越好，安全值需依内存和连接开销而定；8GB内存建议200–400，超500需谨慎；SET GLOBAL仅对新连接生效且不持久；调小该值不能根治连接泄漏，须结合连接池、超时设置与监控。
max_connections 设置多少才安全
MySQL 的 max_connections 不是越大越好，设太高反而容易触发内存耗尽或系统级 OOM。实际安全值取决于服务器内存、每个连接平均内存占用（由 sort_buffer_size、join_buffer_size 等会话变量决定）以及并发查询复杂度。一台 8GB 内存的机器，若每个连接平均吃掉 10MB，保守建议上限控制在 200–400；超过 500 就得仔细核对 innodb_buffer_pool_size 和系统可用内存余量。
线上直接改 max_connections 会不会断连
执行 SET GLOBAL max_connections = 500 是即时生效的，但只影响后续新连接，已建立的连接不受影响，也不会被踢出。不过要注意：如果当前活跃连接数已接近旧上限，新连接会立刻因“Too many connections”被拒——这不是配置没生效，而是旧限制还在起作用。所以调整前建议先用 SHOW STATUS LIKE 'Threads_connected' 查看实时连接数，留出缓冲空间。
修改后不持久？mysqld 重启就恢复默认
仅用 SET GLOBAL 修改只在当前实例生命周期内有效。必须写入配置文件才能持久化：
- Linux 下通常是
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf - 在
[mysqld]段落下添加一行：max_connections = 400 - 改完需重启 MySQL：
systemctl restart mysql（或mysqld，依发行版而定） - 验证是否加载成功：启动后执行
SELECT @@max_connections，结果应与配置值一致
为什么调小了 max_connections 还是被撑爆
单纯压低 max_connections 并不能解决根本问题。常见漏网原因包括：
- 应用层未正确复用连接（比如每次 HTTP 请求都新建 MySQL 连接，且不 close）
- 连接泄漏：代码里开了
Connection但异常路径下没调close()，连接长期处于Sleep状态堆积 - 客户端超时设置过长：
wait_timeout和interactive_timeout默认 8 小时，Sleep 连接不释放，占着名额 - 监控缺失：没定期查
SHOW PROCESSLIST或information_schema.PROCESSLIST，无法及时发现异常长连接
真正防宕机，得配合连接池配置、应用层健康检查、超时收缩策略一起做，max_connections 只是最后一道闸门。
