alter user设置max_user_connections是mysql 5.7+唯一对已有用户立即生效的方案；set global max_user_connections仅设新用户默认值，不影响已存在账号，其限制实际取自mysql.user表中max_user_connections字段值。
直接用 ALTER USER 设置 MAX_USER_CONNECTIONS，是 MySQL 5.7 中唯一推荐、立即生效、无需重启的方案；设为 0 表示不限制，不是禁止登录。
为什么不能用 SET GLOBAL max_user_connections
这个命令只影响「新创建用户」的默认值，对已有账号完全无效。你执行了它，app_user 的连接数照样能飙到几百。真正起作用的只有写在 mysql.user 表里的那个字段——max_user_connections（注意全小写、下划线）。它只在新建连接时校验，且只统计非 Sleep 状态的活跃连接。
常见误操作：
- 执行
SET GLOBAL max_user_connections = 10后去压测app_user，发现毫无限制 → 因为该用户已存在，不受此全局变量影响 - 查
SHOW VARIABLES LIKE 'max_user_connections'发现是 10，就以为生效了 → 这个值只是“新用户的默认值”，和具体账号无关 - 改了
max_connections（全局总闸）以为能控单个用户 → 完全不相关，那是整个实例的上限
如何正确设置并验证 MAX_USER_CONNECTIONS
对已有用户，必须用 ALTER USER 显式指定 Host，且 Host 必须和 SHOW GRANTS FOR 'app_user'@'...' 输出的完全一致：'app_user'@'localhost' 和 'app_user'@'127.0.0.1' 是两个独立账号，要分别设置。
执行示例：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 8;
验证是否真写入成功（别信命令没报错）：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';
关键点：
- 返回值必须是数字
8，不是NULL、0或-1（后三者都等效于“不限制”） - 普通用户查不了
mysql.user，需有SELECT ON mysql.*权限，或用 root 登录验证 -
SHOW GRANTS永远不会显示这个值，因为它不是权限，而是用户属性
连接池配置必须 ≤ 用户限制值
应用层用了 HikariCP、Druid 等连接池，如果 maximumPoolSize > max_user_connections，启动或压测时必然失败，错误日志里会明确出现：
ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource (current value: 8)
这不是网络问题，也不是认证失败，而是 MySQL 主动拒绝——说明限制已生效。但连接池不会自动降级，必须人工调低 maximumPoolSize 或拆分账号。
容易被忽略的细节：
- 连接池维持的 idle 连接（比如 HikariCP 默认保持 10 个空闲连接）仍计入限额，哪怕业务零请求
- 空闲连接未及时释放（
wait_timeout太长）也会卡满配额，需同步检查应用close行为和连接池的idleTimeout配置 - 多个服务共用同一账号（如所有微服务都连
app_user）时，建议按实例分配独立账号，例如app_web1、app_web2，再分别设限
怎么确认当前真实占用数，而不是被 SHOW PROCESSLIST 误导
SHOW PROCESSLIST 会把 Sleep 状态的连接也列出来，但它不计入 MAX_USER_CONNECTIONS 限制。真正决定是否拦新连接的，是「非 Sleep 的活跃连接数」。
查运行时真实占用：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app_user' GROUP BY user;
或者更直观（MySQL 8.0+）：
SELECT * FROM performance_schema.accounts WHERE USER = 'app_user'\G
注意：CURRENT_CONNECTIONS 字段才是当前正在使用的数量，而 max_user_connections 字段是限制值，二者不要混淆。
压测验证最可靠：用该账号反复执行 mysql -u app_user -p -e "SELECT 1;"，超过设定值后第 N+1 次应稳定报错 ERROR 1226。已建立的连接不会被踢，所以重启应用比等超时更有效。
