MySQL 5.7.6+ 支持用户级并发限制，用 CREATE USER 或 ALTER USER 设置 MAX_USER_CONNECTIONS；GRANT 中指定该参数仅对新建用户生效，已有用户须用 ALTER USER；设为0表示不限制。

直接用 CREATE USER 或 ALTER USER 设置最可靠

MySQL 从 5.7.6 起就支持在用户粒度上限制并发连接数，不需要改全局配置、也不依赖 profile（那是 Oracle/YashanDB 的玩法）。核心就是 MAX_USER_CONNECTIONS 这个参数，它写在用户元数据里，每次新建连接时实时校验。

常见错误现象：执行了 GRANT ... WITH MAX_USER_CONNECTIONS 5 却没生效——因为 GRANT 语法只在创建用户时支持该子句；对已有用户必须用 ALTER USER。

• 创建新用户并限制为 3 个并发连接：CREATE USER 'api_user'@'10.20.%' IDENTIFIED BY 'xxx' MAX_USER_CONNECTIONS 3;
• 修改已有用户：ALTER USER 'report_user'@'localhost' MAX_USER_CONNECTIONS 1;
• 设为 0 表示不限制（这是默认值），不是“禁止连接”

查不到 max_user_connections？先确认字段名和权限

查询结果为空或字段为 NULL，大概率是因为你用了旧版 MySQL（mysql.user 表。5.7+ 中该字段叫 max_user_connections（全小写），不是 Max_user_connections 或其他变体。

使用场景：上线前核验、故障排查时快速定位是否真有限制生效。

• 正确查询语句：SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'api_user';
• 如果返回空行，说明用户不存在或拼写错误；如果值为 NULL，说明未设置，等同于 0（无限制）
• 普通账号默认无权查 mysql.user，需 SELECT 权限，或用 root 登录验证

连接被拒时看到 ERROR 1226 (42000) 就对了

这不是配置失败，恰恰是限制起效的明确信号。MySQL 不会静默丢弃连接，而是抛出标准错误，方便应用层捕获重试或降级。

性能影响几乎为零：该检查发生在认证后、会话初始化前，不涉及锁或复杂计算；但要注意连接池行为——比如 HikariCP 默认保持 10 个 idle 连接，哪怕业务只发 1 个请求，也会立刻占满 MAX_USER_CONNECTIONS = 5 的限额。

• 典型报错：ERROR 1226 (42000): User 'api_user' has exceeded the 'max_user_connections' resource limit
• 已建立的连接不会被主动断开，只拦新连接；所以重启应用比等超时更有效
• 连接来自不同 host（如 'user'@'10.20.1.1' 和 'user'@'10.20.1.2'）算两个独立用户，互不影响

max_connections 和 max_user_connections 别混了

前者是全局总闸，后者是每个用户的分闸。调高 max_connections 解不了单个用户疯建连接的问题，反而可能掩盖真实瓶颈。

容易踩的坑：有人在 my.cnf 里加了 max_user_connections = 10，以为所有用户都受控——其实这只是未显式设置用户的默认上限，已有用户仍按自己字段值走，优先级更低。

• 查全局当前值：SHOW VARIABLES LIKE 'max_connections';
• 查历史峰值（比当前值更有参考价值）：SHOW GLOBAL STATUS LIKE 'Max_used_connections';
• 真正要管住某个 API 账号，永远优先动 ALTER USER ... MAX_USER_CONNECTIONS，别碰全局配置

最常被忽略的一点：连接限制只作用于「前台连接」（FOREGROUND），即普通客户端会话；后台线程（如复制 IO/SQL 线程、事件调度器）不计入。所以监控时别用 Threads_connected 直接对比，得查 performance_schema.threads 并过滤 TYPE = 'FOREGROUND'。