修改max_connections需同步调整配置文件和systemd限制，否则易失效或重启回退；应优先分析Max_used_connections、Threads_connected及慢查询，避免盲目调高导致内存耗尽或性能下降。
改 max_connections 不能只改 MySQL 配置，否则大概率不生效，甚至重启后倒退到默认值 151。
查清当前值和真实压力点
别一上来就改。先确认两个关键数字：max_connections 是你设的上限，Max_used_connections 才是你历史上真正用过最高的并发连接数——后者比前者重要得多。
执行这两条命令：
SHOW VARIABLES LIKE 'max_connections';<br>SHOW GLOBAL STATUS LIKE 'Max_used_connections';
如果 Max_used_connections 长期在 max_connections 的 80% 以上，说明快顶不住了；如果常年只有 20–30，那调高只是浪费内存，还可能引发锁竞争和上下文切换开销。
另外，Threads_connected 可以实时看当前连了多少个，配合慢查询日志一起看——多数 “Too many connections” 根源不是上限低，而是有长事务或没释放的连接把池子堵死了。
动态设置 SET GLOBAL max_connections 为什么常失效
这条命令确实能立刻生效，但有三个硬限制你容易忽略：
- 不能超过 MySQL 编译时的硬编码上限（默认 100000），超了会报
ERROR 1238 (HY000): Variable 'max_connections' is a read only variable - 不能超过操作系统对进程打开文件数的限制（
ulimit -n），常见 systemd 服务默认卡在 1024，哪怕你设了 5000，MySQL 启动时也会默默截断成 1024 - 它只在当前进程生命周期内有效，MySQL 一重启就回退到配置文件值——很多人改完以为搞定，结果半夜服务自动重启，错误又来了
所以它只适合救火：比如线上突然爆满，先顶住，再安排后续永久调整。
永久修改必须配文件 + 改 systemd 服务单元
在 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 段下加一行：
[mysqld]<br>max_connections = 1000
但这只是第一步。systemd 管理的服务（CentOS 7+/Ubuntu 16.04+）默认不会放行高文件描述符数，必须同步改服务单元文件：
- 编辑
/usr/lib/systemd/system/mysqld.service（或mariadb.service） - 在
[Service]下加两行：LimitNOFILE=10000和LimitNPROC=10000 - 执行
systemctl --system daemon-reload，再systemctl restart mysqld
改完立刻验证：cat /proc/$(pidof mysqld)/limits | grep "Max open files"，确保第一列 ≥ 你设的 max_connections + 50；再进 MySQL 查 SHOW VARIABLES LIKE 'max_connections'，确认数值对得上。
调高连接数前必须检查的三件事
max_connections 不是越大越好，盲目拉高反而拖垮性能：
- 每个连接至少占几 MB 内存（尤其开了
sort_buffer_size、join_buffer_size），连接翻倍，内存占用可能翻倍还多，Linux OOM Killer 可能直接杀掉mysqld - 线程调度开销随连接数非线性增长，实测从 200 调到 2000 后 QPS 反而下降 15%
- 云数据库（如阿里云 RDS）通常限制更严，部分实例不支持动态改，得走控制台或工单；有些版本甚至把
max_connections绑定到规格，扩容要升配
真正该盯的是 Threads_running（当前活跃执行中的连接）、慢查询日志、以及应用层是否用了连接池并设置了合理超时——系统级限制、内存水位、真实并发压力，这三样没摸清之前，光改 max_connections 就像给漏水的桶拼命加水。
