必须用alter user 'app_user'@'%' with max_user_connections 30设置单用户连接上限，它不改权限、不重启、立即生效；多host需分别设置，设0不推荐，须查mysql.user表和performance_schema.threads验证。
MySQL 8.0 中防止并发击穿，不能只调高 max_connections，必须分层控制：全局连接池上限 + 单用户连接数限制 + 空闲连接自动回收，三者缺一不可。
怎么用 ALTER USER 限制单个用户的最大连接数
生产环境最常用、最安全的方式是给已有账号加限流，不改权限、不重启、立即生效：
-
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 30;—— 这条语句只改连接数，密码、SSL、权限全保留 - 如果该用户有多个 host（如
'app_user'@'localhost'和'app_user'@'192.168.1.%'），必须分别执行ALTER USER，它们在 MySQL 内部是完全独立的账户 - 设为
0表示不限制（退回到全局max_connections约束），线上环境不建议留0 - MySQL 8.0+ 不需要
FLUSH PRIVILEGES，权限缓存自动刷新
为什么不能只靠 SET GLOBAL max_connections 撑住流量
单纯调高全局连接数，往往掩盖真实问题，甚至加速资源耗尽：
- 每个连接默认占用约 256KB–1MB 内存，
max_connections = 2000可能直接吃掉 2GB+ 内存 - Linux 系统级限制会卡死：若
ulimit -n或 systemd 的LimitNOFILE仍为默认 1024，MySQL 启动时就会报Too many open files - 大量
Sleep连接堆积在information_schema.PROCESSLIST里，说明连接没释放，不是“不够连”，而是“连了不走” -
wait_timeout默认 28800 秒（8 小时），线上应设为300–600秒，否则空闲连接长期占 slot
如何验证 MAX_USER_CONNECTIONS 是否真正生效
改完不验证等于白改，两个检查点必须同时满足：
- 查系统表确认配置写入：
SELECT User, Host, Max_user_connections FROM mysql.user WHERE User = 'app_user';—— 返回值必须是你设的数字，不能是0或NULL - 查实时活跃连接：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app_user' GROUP BY user;—— 这个COUNT是当前真正占用的连接数，超限时新连接会直接拒绝，报错ERROR 1226 (42000) - 手动压测验证：用该账号连续执行
mysql -u app_user -p -e "SELECT 1;"超过设定值，第 N+1 次应明确失败
my.cnf 里 max_connections 修改后不生效的常见原因
很多人改完配置文件发现没用，八成栽在这几个地方：
- 没确认 MySQL 实际加载的配置路径：执行
mysql --help | grep "Default options"或查错误日志中的my.cnf路径，宝塔等面板常把配置文件放在/www/server/mysql/etc/my.cnf，而非/etc/my.cnf - 修改位置错误：必须放在
[mysqld]段内，写在[client]或段外无效 - 没重启服务：仅
systemctl reload mysqld不生效，必须systemctl restart mysqld - 系统级限制未同步：
/etc/security/limits.conf和/etc/systemd/system/mysqld.service.d/override.conf中的LimitNOFILE必须同步调高，否则 MySQL 启动就失败
真正防击穿的关键不在“能连多少”，而在于“谁连、连多久、连了干啥”。MAX_USER_CONNECTIONS 是隔离层，wait_timeout 是回收机制，ulimit 是底层兜底——漏掉任意一层，都可能在凌晨三点被一个泄漏的连接池拖垮整套服务。
