mysql 5.7+ 中需用 alter user 或 grant 显式设置 max_user_connections 才生效，create user 中指定无效；设为 0 表示不限制；修改后立即生效，无需重启或 flush privileges。
mysql 5.7+ 怎么用 max_user_connections 限制单个用户的并发连接数
直接生效，不需要重启 mysql，但必须用 grant 或 alter user 显式设置，仅靠创建用户时指定无效。
常见错误是以为在 CREATE USER 里写了 MAX_USER_CONNECTIONS 5 就完事了——其实这条语句会被忽略（除非同时带 GRANT），真正起作用的是权限系统里的配额记录。
-
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 3;是最稳妥的写法（MySQL 5.7.6+） - 如果用
GRANT，必须包含任意权限 +WITH MAX_USER_CONNECTIONS 3，例如：GRANT SELECT ON mydb.* TO 'app_user'@'%' WITH MAX_USER_CONNECTIONS 3; - 设为
0表示不限制（不是“禁止连接”，这点容易误解） - 修改后无需
FLUSH PRIVILEGES，权限表变更立即生效
为什么 wait_timeout 和 max_connections 不等于用户级并发控制
这两个参数常被误当作“限制用户连接数”的替代方案，但它们解决的是完全不同的问题。
-
max_connections是全局总连接数上限，所有用户共享；超限后新连接会报错Too many connections，但不区分用户 -
wait_timeout控制空闲连接自动断开时间，影响的是连接生命周期，不是并发数量——活跃连接仍可无限增长（只要没超max_connections） - 真实业务中，一个用户开 20 个长连接、另一个只开 1 个，
max_connections压根不管这个分布，而MAX_USER_CONNECTIONS才能按需隔离
MySQL 5.6 及更早版本怎么处理
不支持 ALTER USER ... WITH MAX_USER_CONNECTIONS，只能靠手动更新系统表，且有严格前提。
- 必须用
root登录，并执行：UPDATE mysql.user SET max_user_connections = 5 WHERE User = 'app_user' AND Host = '%'; - 之后必须运行
FLUSH PRIVILEGES;，否则不生效 - 该方式在 MySQL 5.7+ 中已被标记为过时，升级后可能失效；且无法动态验证配额是否加载成功（没有对应状态变量）
- 强烈建议升级到 5.7+，避免因权限表结构变化导致配置丢失
验证和监控：怎么确认限制真的起了作用
不能只看命令是否执行成功，得观察实际行为。最容易被忽略的是“连接未被拒绝，但查询卡住”这类现象——其实是连接建立成功了，只是后续语句被排队或阻塞。
- 查当前配额：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user'; - 查该用户当前活跃连接数：
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE USER = 'app_user'; - 当第
n+1个连接尝试建立时，会明确报错：ER_USER_LIMIT_REACHED: User 'app_user' has exceeded the 'max_user_connections' resource (current value: 3) - 注意：连接池（如 HikariCP）可能复用连接，看起来“超限却没报错”，要关掉连接池或清空连接池后再测
实际配置时，MAX_USER_CONNECTIONS 的值往往比应用预设的连接池大小略高一点，留出管理连接、临时脚本等余量；但一旦设得太低，又容易引发偶发性连接拒绝，排查起来反而更费劲。
