alter user是唯一有效方式，set global max_user_connections仅影响新用户默认值；必须用alter user 'user'@'host' with max_user_connections n显式设置，主机名须完全匹配，设0表示不限制，验证需查表+实测触发error 1226。
ALTER USER 是唯一有效方式，SET GLOBAL 完全无效
执行 SET GLOBAL max_user_connections = 5 对已有用户不起作用——它只影响后续新创建用户的默认值，不会修改 mysql.user 表中任何现存账号的 max_user_connections 字段。你查 SELECT User, Host, max_user_connections FROM mysql.user 会发现目标用户字段仍是 NULL 或旧值。
真正生效的写法必须用 ALTER USER 显式绑定用户身份：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 5;ALTER USER 'report_user'@'localhost' WITH MAX_USER_CONNECTIONS 1;- 主机名部分（
@后）必须和SHOW GRANTS FOR 'app_user'@'host'输出完全一致：'app_user'@'127.0.0.1'和'app_user'@'localhost'是两个独立账号，需分别设置
设为 0 不等于禁止连接，而是退回到全局限制
MAX_USER_CONNECTIONS 0 表示不限制该用户并发数（等同于未设置），实际仍受 max_connections 全局上限兜底。线上环境不建议留 0，容易被忽略导致资源耗尽。
设为 1 则真只允许 1 个活跃连接，第 2 次新建连接会立即失败，报错：ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource (current value: 1)。这不是网络超时或认证失败，是 MySQL 在握手阶段就拒绝连接。
注意：max_connections 是实例总闸，MAX_USER_CONNECTIONS 是用户分闸，两者叠加生效：单个用户连接数 ≤ 自身限制，且所有用户连接总数 ≤ max_connections。
验证是否生效不能只看 SHOW PROCESSLIST
SHOW PROCESSLIST 显示的是当前已建立的连接，而 MAX_USER_CONNECTIONS 只在校验**新建连接**时触发。即使你设了 3，看到 6 个连接也不代表配置失效——旧连接不会被踢，只是新连接连不上。
可靠验证方式有三步：
- 查表确认：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';，返回值必须是你设的数字，不是NULL或 0 - 查实时活跃连接：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app_user';（需确保performance_schema已启用） - 实测触发：开多个终端，并发执行
mysql -u app_user -p -e "SELECT 1;"，第 N+1 次（N 是你设的上限）应明确报错ERROR 1226
连接池配置必须 ≤ 用户限制值，否则必然失败
应用层若用 HikariCP、Druid 等连接池，其 maximumPoolSize（或等效参数）必须 ≤ 对应账号的 MAX_USER_CONNECTIONS 值。否则启动或压测时必然触发 ERROR 1226，且连接池不会自动降级或重试。
常见踩坑点：
- 多个微服务共用同一账号（如
'app'@'%'），但各自连接池都配了 20，总连接数轻松突破 100 - 连接池 idle 配置不合理或应用未正确 close，大量
Sleep连接卡满配额 - 误以为限制生效后会主动断开旧连接——实际上只拦新连接，重启应用比等超时更有效
最易被忽略的点是：限制生效在连接认证阶段，但连接池会在应用启动时就批量建连，一上来就可能直接打满限额，根本没机会让业务请求进来。
