要让调整真正生效，MySQL 配置、systemd 限制和资源水平必须一起联动处理，否则很容易出现配置不生效，或者重启后又回退的情况。更稳妥的做法是，先看清楚 Max_used_connections、Threads_connected 以及慢查询这些关键指标，再决定怎么调；如果不加分析就一味把参数往上抬，结果往往不是更稳，而是内存被吃满，性能反而下滑。
调高 MySQL 最大连接数不能只改一个地方，必须同步处理 MySQL 配置、系统级限制和资源水平，否则大概率不生效或重启后回退。
先看真实压力，别急着调
登录 MySQL 执行两条命令：
- SHOW VARIABLES LIKE 'max_connections'; —— 看当前设的上限
- SHOW GLOBAL STATUS LIKE 'Max_used_connections'; —— 看历史上真正用过的最高并发数
如果 Max_used_connections 长期在 max_connections 的 80% 以上，说明确实快撑不住；如果常年只有 20–50，盲目调高只会浪费内存、加剧线程竞争。
再顺手查一下：SHOW STATUS LIKE 'Threads_connected'; 实时看现在连了多少个，结合慢查询日志判断是不是有长事务或未释放连接把池子堵死了。
永久修改要配三处
只改 my.cnf 是不够的，MySQL 启动时会受操作系统限制“截断”你的设置：
- 在 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 段下加：
max_connections = 1000 - 检查 systemd 服务限制：编辑 /usr/lib/systemd/system/mysqld.service（或 mariadb.service），在 [Service] 下加：
LimitNOFILE=10000
LimitNPROC=10000 - 执行重载与重启：
systemctl --system daemon-reload
systemctl restart mysqld
改完立刻验证：SHOW VARIABLES LIKE 'max_connections'; 必须返回你设的值，否则就是某处被系统卡住了。
临时救火可以 SET GLOBAL，但有硬约束
线上突然爆满时可用：
- SET GLOBAL max_connections = 1000; —— 立刻生效，不用重启
- 但它受三个限制：
• 不能超 MySQL 编译上限（默认 100000）
• 不能超 ulimit -n 设置（常见默认 1024）
• MySQL 进程重启后自动还原
所以它只是应急手段，不能替代配置文件修改。
调高之后必须盯住资源和行为
每个连接至少占用 1–2MB 内存（尤其开了 sort_buffer、join_buffer 时），连接数翻倍，内存可能翻倍还多。更隐蔽的是性能拐点：
- CPU 上下文切换开销明显上升
- 锁竞争加剧，QPS 反而下降
- Threads_running（活跃线程）持续高于 50，说明真正在干活的连接已饱和
这类问题最好结合监控一起看：先用 SHOW PROCESSLIST 把连接来源和正在执行的 SQL 摸清楚，再打开慢查询日志去定位真正卡住的环节。到了应用端，连接池一定要启用，比如 HikariCP，同时把 maximumPoolSize 和 idle timeout 这些参数按实际负载设置到位。
