alter user是mysql 5.7.6+设置max_user_connections的唯一推荐方式，create user建用户时也可用with子句；设为0表示不限制，修改后立即生效，需查mysql.user表验证，且连接池配置须≤该值。
ALTER USER 设置 MAX_USER_CONNECTIONS 是唯一推荐方式
MySQL 5.7.6+ 必须用 ALTER USER（或建用户时用 CREATE USER ... WITH MAX_USER_CONNECTIONS），别碰 SET GLOBAL max_user_connections——它只影响新用户的默认值，对已有账号完全无效。
执行示例：ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 20;
-
'app_user'@'%'中的Host必须和SHOW GRANTS FOR 'app_user'@'...';输出的完全一致，'app_user'@'localhost'和'app_user'@'127.0.0.1'是两个独立账号 - 设为
0表示不限制（依赖全局max_connections），不是“禁止登录” - 修改后立即生效，无需
FLUSH PRIVILEGES（MySQL 8.0.16+ 自动刷新；5.7.6–8.0.15 也自动生效） - 该限制只校验新建连接，已存在的超限连接不会被中断
查 mysql.user 表确认是否真生效
别只信命令没报错，SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user'; 才是唯一可靠验证方式。
注意几个易错点：
- MySQL 8.0+ 的
mysql.user表里字段名仍是max_user_connections（小写+下划线），不是MAX_USER_CONNECTIONS - 如果查出来是
NULL或-1，说明未显式设置，行为等同于0（不限） - 普通用户无权查此表，需具备
SELECT ON mysql.*权限 -
SHOW GRANTS不会显示该限制，因为它不是权限，而是用户属性
连接池配置必须 ≤ 用户限制值
应用层用 HikariCP、Druid 等连接池时，若 maximumPoolSize > max_user_connections，启动或压测时必然出现连接失败，错误日志里会看到类似：User 'app_user' has exceeded the 'max_user_connections' resource (current value: 10)。
- 这个错误码是
ER_USER_LIMIT_REACHED（错误号 1226），不是网络超时或认证失败 - 连接池不会自动降级或重试，需人工调整
maximumPoolSize或拆分账号 - 若多个服务共用同一账号（如微服务都连
'app'@'%'），建议按实例分配独立账号，例如'app_web1'@'10.0.1.10'和'app_web2'@'10.0.1.11'，再分别设限 - 空闲连接未释放（比如
wait_timeout太长）也会卡满配额，需同步检查应用 close 行为和连接池 idle 配置
旧版本 MySQL 5.6 及更早只能手动改系统表
低于 5.7.6 的版本不支持 WITH MAX_USER_CONNECTIONS 语法，必须走 UPDATE mysql.user + FLUSH PRIVILEGES。
操作步骤：UPDATE mysql.user SET max_user_connections = 15 WHERE User = 'app_user' AND Host = '%'; FLUSH PRIVILEGES;
- 执行前务必先
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';确认目标行存在且唯一 -
FLUSH PRIVILEGES不可省略，否则修改不生效 - MySQL 8.0+ 已移除
max_user_connections字段，此法在 8.0+ 会报错Unknown column 'max_user_connections' in 'field list' - 手动插入用户时若该字段为
NULL，需显式设为数字（如0或10）才生效
User+Host 组合，不区分客户端 IP、不累计历史连接、不触发自动清理。最容易忽略的是——你以为设了限制就万事大吉，但连接池没调、应用没关连接、账号复用没拆分，照样会爆。
