alter user是唯一有效方式，set global和grant对已有用户均无效；必须精确匹配user@host、查mysql.user表验证、实测触发error 1226，并确保连接池配置≤限制值。
必须用 ALTER USER 设置 MAX_USER_CONNECTIONS，其他方式（SET GLOBAL、GRANT）对已有用户完全无效。
为什么 SET GLOBAL max_user_connections 不起作用
这个命令只影响后续新建用户的默认值，不会修改任何现存账号的限制。执行后查 mysql.user 表，目标用户的 max_user_connections 字段仍是 NULL 或旧值。压测时突然爆出 ERROR 1226，往往就是误信了这个“全局设置”。
-
SHOW VARIABLES LIKE 'max_user_connections'返回的值只是新用户的模板，和具体账号无关 - 改
max_connections（全局总闸）跟单个用户限制毫无关系 - MySQL 5.7+ 中该字段名严格为小写
max_user_connections，不是驼峰或大写变体
如何正确设置并立即生效
对已有用户，唯一有效语法是 ALTER USER 'user'@'host' WITH MAX_USER_CONNECTIONS N，且 User@Host 必须和 SHOW GRANTS FOR 'user'@'host' 输出完全一致。
-
'app_user'@'localhost'和'app_user'@'127.0.0.1'是两个独立账号，需分别执行 - 设为
0表示不限制（退回到全局max_connections约束），不是禁止登录 - 设为
1就真只允许 1 个活跃连接，第 2 次新建连接会立刻报错：ERROR 1226 (42000) - 修改后立即生效，无需
FLUSH PRIVILEGES，也不重启 MySQL
验证是否真生效：查表 + 实测缺一不可
别信命令没报错就以为成功。唯一可信路径是两步：确认字段值、触发超限错误。
- 查配置：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';—— 返回值必须是你设的数字，不能是NULL或0 - 查实时连接（需开启
performance_schema）：SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app_user'; - 实测触发：开多个终端，并发执行
mysql -u app_user -p -e "SELECT 1;"，第N+1次（N是你设的上限）应明确报错ERROR 1226
连接池配置必须 ≤ 用户限制值
这是最容易被忽略的落地环节。HikariCP 的 maximumPoolSize、Druid 的 maxActive 等参数，必须 ≤ 对应账号的 MAX_USER_CONNECTIONS 值。
- 否则应用启动或首次压测就会失败，错误日志反复出现
ERROR 1226 - 连接池默认维持 idle 连接，哪怕业务流量为零，也会立刻占满配额
- 多个微服务共用同一账号（如
'app'@'%'）时，总连接数会叠加突破限制——建议按实例拆分账号
真正生效的只有写在 mysql.user 表里的那个字段，且校验只发生在新建连接瞬间；已存在的连接不会被中断，也不会自动降级重试。配置写进去了，不代表连接池或客户端会守规矩。
