SET GLOBAL max_user_connections对已有用户完全无效，因为它仅影响新用户的默认值，不修改现存账号的max_user_connections字段；正确方式是用ALTER USER 'user'@'host' WITH MAX_USER_CONNECTIONS N显式设置，且主机名必须精确匹配，修改后立即生效并需查mysql.user表验证。
必须用 ALTER USER 或 CREATE USER 显式设置 MAX_USER_CONNECTIONS，SET GLOBAL max_user_connections 对已有用户完全无效。
为什么 SET GLOBAL max_user_connections 不起作用
这个语句只影响后续新创建用户的默认值，不会修改任何现存账号的限制。执行后查 mysql.user 表，你会发现目标用户的 max_user_connections 字段仍是 NULL 或旧值。它不是“全局开关”，而是“新用户模板”。线上环境若误信此命令已生效，容易在压测或流量突增时突然触发 ERROR 1226。
正确设置方式：用 ALTER USER 修改已有用户
语法必须带 WITH 关键字，且 User@Host 必须和 SHOW GRANTS FOR 'user'@'host' 输出完全一致：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 5;ALTER USER 'report_user'@'localhost' WITH MAX_USER_CONNECTIONS 1;- 如果用户是
'app_user'@'127.0.0.1'，就不能写成'app_user'@'localhost'——MySQL 视为两个独立账号 - 修改后立即生效，无需
FLUSH PRIVILEGES（MySQL 5.7.6+ 均自动刷新）
验证是否真生效，不能只看命令输出
唯一可信路径是查表 + 实测新建连接：
- 查配置：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';—— 注意字段名是全小写max_user_connections，不是大写或驼峰 - 查实时活跃连接（需开启
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 (42000): User 'app_user' has exceeded the 'max_user_connections' resource (current value: 5)
连接池配置必须 ≤ 用户限制值
这是最容易被忽略的落地环节：
- HikariCP 的
maximumPoolSize、Druid 的maxActive等参数，必须 ≤ 对应账号的MAX_USER_CONNECTIONS值 - 否则应用启动或首次压测就会失败，错误日志里反复出现
ERROR 1226，连接池不会自动降级或重试 - 多个微服务共用同一账号（如
'app'@'%'）时，总连接数会叠加突破限制——建议按实例拆分账号，例如'app_web1'@'10.0.1.10'和'app_web2'@'10.0.1.11'，再分别设限 - 空闲连接未释放（比如
wait_timeout过长或连接池 idle 配置不合理）也会卡满配额，需同步检查应用close()行为
真正生效的限制只在校验新建连接时触发，已存在的连接不会被中断；但连接池维持 idle 连接的行为会让配额瞬间占满，所以配置不匹配时，问题往往在启动阶段就暴露出来，而不是等业务高峰期才显现。
