alter user是mysql 5.7.6+设置单用户最大连接数的唯一有效方式；set global max_user_connections仅影响新用户默认值，对已有用户无效；需精确匹配host、查mysql.user确认配置、结合performance_schema验证真实活跃连接，并确保连接池配置≤该限制。
ALTER USER 是设置 MAX_USER_CONNECTIONS 的唯一有效方式
执行 SET GLOBAL max_user_connections = 5 对已有用户完全无效——它只影响后续新创建用户的默认值。真正起作用的，是每个账号在 mysql.user 表中独立存储的 max_user_connections 字段。MySQL 5.7.6+ 必须用 ALTER USER 显式修改，例如：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 10;
注意：'app_user'@'%' 中的 host 必须和 SHOW GRANTS FOR 'app_user'@'...'; 输出的完全一致；'app_user'@'localhost' 和 'app_user'@'127.0.0.1' 是两个不同账号，需分别设置。
设为 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 在握手阶段就拒绝了连接请求。
验证是否生效不能只看 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';，这个才是当前活跃连接数 - 实测校验：开多个终端，依次执行
mysql -u app_user -p -e "SELECT 1;"，第 N+1 次（N 是你设的上限）应直接报错ER_USER_LIMIT_REACHED
连接池配置必须 ≤ 用户限制值
应用层若用 HikariCP、Druid 或其他连接池，其 maximumPoolSize（或等效参数）必须 ≤ 对应账号的 MAX_USER_CONNECTIONS 值。否则启动或压测时必然触发 ERROR 1226，且连接池不会自动降级或重试。
常见踩坑点：
- 多个微服务共用同一账号（如
'app'@'%'），但各自连接池都配了 20，结果总连接数轻松突破 100 -
wait_timeout设得过大（默认 8 小时），空闲连接长期挂着，占满配额后新请求全被拒 - 应用没调
close()或连接池未启用 idle 清理，导致“僵尸连接”堆积
真正容易被忽略的是：限制生效后，旧连接不会自动释放——资源腾不出来，新连接就卡在门外。这和配置有没有生效无关，而是应用侧资源管理的问题。
