能临时生效，但需满足三个前提：当前活跃连接未达上限、mysql硬限制与系统资源（如文件描述符）足够、执行用户具备super或system_variables_admin权限。
能，但只限临时生效，且必须满足三个前提条件。直接执行 SET GLOBAL max_connections = 1000 就行，但它不会“释放”已占连接，也不能绕过系统级限制，更不能替代配置文件修改。
为什么 SET GLOBAL 看似成功却没效果？
常见现象是命令返回 Query OK，但应用依然报 Too many connections。原因往往不是 SQL 没执行，而是：
- 当前已有 150 个活跃连接，而你设成 1000 —— 这只是允许第 151～1000 个新连接进来，不解决现有阻塞
- MySQL 编译时硬上限低于你设的值（如 65535），但实际受内存或 OS 文件描述符拖累
- systemd 服务单元限制了
LimitNOFILE，MySQL 进程根本拿不到足够 fd 来建立新 socket - 用户权限不足：执行者必须有
SUPER或SYSTEM_VARIABLES_ADMIN权限
执行 SET GLOBAL 前必须确认的三件事
别跳过验证，否则白操作：
- 先查当前值：
SHOW VARIABLES LIKE 'max_connections'; - 再看真实占用：
SHOW STATUS LIKE 'Threads_connected';，如果长期接近上限，说明连接泄漏比扩容更紧急 - 检查是否被 systemd 截断：
systemctl show mysql | grep LimitNOFILE，若显示LimitNOFILE=1024，那即使设成 1000，也大概率卡在 900 左右就失败
临时调高后仍连不上？立刻查这三点
不是配置没生效，而是底层资源拦住了：
- 运行
cat /proc/$(pgrep mysqld)/limits | grep "Max open files"，确认 MySQL 进程实际获得的文件描述符数 ≥ 你设的max_connections值 + 200（留出日志、表缓存等） - 检查错误日志：
sudo tail -20 /var/log/mysql/error.log，出现Can't create thread或Too many open files就是系统级瓶颈 - 用
lsof -p $(pgrep mysqld) | wc -l统计当前 mysqld 占用的 fd 总数，远超max_connections值说明有未关闭的句柄（比如慢查询、长事务、Sleep 连接堆积）
真正卡住的时候，SET GLOBAL 只是止痛药；根因通常在应用端连接未释放、wait_timeout 过长、或 systemd 的 LimitNOFILE 没同步放开。改完记得盯 5 分钟 SHOW PROCESSLIST，看 Sleep 连接是否持续增长——那才是该修的地方。
