mysql不支持alter system语句，调连接数须用show variables和show status查看，通过set global临时调整max_connections，永久生效需修改my.cnf并配置wait_timeout防sleep连接堆积。
MySQL没有ALTER SYSTEM语句，这个命令在PostgreSQL或Oracle里才有，直接用会报错ERROR 1064。想调连接数，得走MySQL自己的路。
查当前连接和上限值必须用SHOW VARIABLES和SHOW STATUS
别信网上搜到的“ALTER SYSTEM SET max_connections=2000”——MySQL根本不认。正确姿势是：
- 看上限：
SHOW VARIABLES LIKE 'max_connections'; - 看已用：
SHOW STATUS LIKE 'Threads_connected'; - 看活跃线程数（更关键）：
SHOW STATUS LIKE 'Threads_running';，如果这个接近max_connections，才是真扛不住了
注意：Threads_connected包含大量Sleep连接，光看它容易误判。真正压垮数据库的，往往是Threads_running持续高于30–50（取决于服务器配置）。
临时调高max_connections只能用SET GLOBAL
线上出问题时，最快速有效的方式是动态修改，不用重启：
- 执行：
SET GLOBAL max_connections = 2000; - 验证是否生效：
SHOW VARIABLES LIKE 'max_connections'; - 这个改动只在当前MySQL进程生命周期内有效，重启后会回落到配置文件值
⚠️ 风险点：盲目设太高（比如5000+）可能触发系统级限制，比如Linux的ulimit -n不够，导致MySQL启动失败或运行中崩溃；也要算内存账——每个连接至少占用256KB左右内存，2000连接≈500MB额外开销。
永久生效必须改my.cnf，但别漏掉wait_timeout
在[mysqld]段落加这两行才是稳妥做法：
max_connections = 1000 wait_timeout = 60
为什么wait_timeout关键？
- 默认是28800秒（8小时），意味着空闲连接挂8小时才断，大量
Sleep连接堆积就是它导致的 - 设成60–300秒，能让应用端不规范关闭连接时，MySQL自动回收，避免“连接没满，但全是僵尸”的假性爆满
- 改完必须重启MySQL：
systemctl restart mysqld（CentOS/RHEL）或service mysql restart（Ubuntu/Debian）
别只改max_connections就以为万事大吉——很多团队调到2000还爆满，最后发现wait_timeout仍是默认8小时，几百个Sleep连接占着茅坑不拉屎。
MySQL 8.0+有admin接口，但别依赖它救火
8.0.14+支持独立管理端口（如admin_port=33062），允许带SUPER或service_connection_admin权限的用户绕过连接限制登录。但它不是万能解药：
- 需要提前配置并开启，故障发生时若没配好，照样进不去
- 它只是留了一条管理员逃生通道，不能解决连接数本身过载的问题
- 日常运维仍要靠
max_connections+wait_timeout+ 连接池规范这三板斧
真正容易被忽略的，是应用层——哪怕MySQL设到3000，如果Java服务用的是无池直连、且没写connection.close()，或者Druid配置了maxActive=1000却没配minIdle和removeAbandonedOnBorrow，连接照样会漏、会堆、会爆。
