必须同步调整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。
