MySQL单用户连接数限制必须用MAX_USER_CONNECTIONS，它是绑定在'user'@'host'上的账户级资源属性，认证阶段硬拦截；ALTER USER是修改已有用户限制的唯一推荐方式，仅更新mysql.user表中Max_user_connections字段且立即生效。
MySQL 单用户连接数限制必须用 MAX_USER_CONNECTIONS，不是靠全局变量或权限位控制，也不是靠 GRANT 普通权限实现——它是个账户级资源属性，绑定在 'user'@'host' 上，认证阶段硬拦截。
ALTER USER 是修改已有用户连接限制的唯一推荐方式
对已上线账号，ALTER USER 是最安全、最直接的操作。它不改动权限列表，只更新 mysql.user 表里的 Max_user_connections 字段，且立即对新连接生效。
-
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 8;—— 设为 8，超了新连接直接报错 - 设为
0表示取消该用户的单独限制（退回到受全局max_connections约束） - 主机名必须完全匹配：如果用户是
'app_user'@'192.168.1.100'，就不能用'app_user'@'%'去 ALTER - 执行后旧连接不受影响，限制只作用于后续新建连接
CREATE USER 时指定 MAX_USER_CONNECTIONS 仅在 MySQL 5.7+ 有效
MySQL 5.7 及以上版本支持在 CREATE USER 语句中直接带 WITH MAX_USER_CONNECTIONS N；但老版本（如 5.6）会静默忽略该子句，必须靠 GRANT USAGE 补救。
CREATE USER 'api_user'@'10.0.0.%' IDENTIFIED BY 's3cr3t' WITH MAX_USER_CONNECTIONS 3;- 如果创建后发现没生效，查
SELECT User, Host, Max_user_connections FROM mysql.user WHERE User = 'api_user';确认值是否为 3 - 5.6 或更早版本只能走
GRANT USAGE ON *.* TO 'api_user'@'10.0.0.%' WITH MAX_USER_CONNECTIONS 3;
别碰 SET GLOBAL max_user_connections —— 它只是默认值兜底
SET GLOBAL max_user_connections = 5; 不会影响任何已有用户，只决定「今后新建但未显式设置 MAX_USER_CONNECTIONS 的用户」的默认上限。它不是开关，也不是总闸。
- 已存在用户不受影响，哪怕你刚设了全局为 5，老用户仍按自己表里存的值走
- 这个变量在配置文件里写进
[mysqld]段也一样，只是新用户默认值，不是运行时策略 - 真正混淆点在于错误日志里报的
ER_USER_LIMIT_REACHED错误，源头永远是单个账户的Max_user_connections字段，不是这个全局变量
验证限制是否真起作用，得模拟超限连接
光查 mysql.user 表只是看配置，不代表运行时拦截有效。必须实测：开多个连接直到突破上限。
- 用脚本循环连：
for i in {1..10}; do mysql -u app_user -p'pwd' -e "SELECT 1;" & done - 第
N+1个连接（N 是你设的MAX_USER_CONNECTIONS）应立刻返回：ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource (current value: N) - 注意连接池场景：一个连接池维持 10 个空闲连接，就直接占满配额，应用层不 close 就永远卡住
最容易被忽略的是 host 匹配精度和连接池残留连接——'user'@'localhost' 和 'user'@'127.0.0.1' 是两个独立账户，各自有配额；而连接池不释放连接时，MAX_USER_CONNECTIONS 会一直卡在上限，看起来像“限制失效”，其实是连接没断。
