max_user_connections 是 MySQL 限制单个用户并发连接数的全局变量，但仅对显式新建连接生效，不约束已有连接、内部线程或代理复用连接；需配合 GRANT 的 MAX_USER_CONNECTIONS 子句实现细粒度控制，且设为 0 表示不限。
max_user_connections 是什么，为什么它不总是生效
max_user_connections 是 MySQL 中限制单个用户并发连接数的全局变量，但它的作用范围仅限于「显式创建的新连接」，对已存在的连接、内部线程（如复制IO/SQL线程）、或通过代理（如 ProxySQL、HAProxy）复用的连接无约束。常见错误是以为设成 10 就能防爆连，结果发现慢查询堆积、连接池打满、甚至 Too many connections 仍报错——那是因为 max_user_connections 不影响 max_connections 的总闸，也不管连接空闲多久才释放。
实操建议：
- 先确认你真正想控的是「用户级并发」还是「整体资源压测阈值」：前者用
max_user_connections，后者得靠max_connections+ 连接池 timeout 配合 - 该变量在运行时可动态修改，但只对后续新建连接生效：
SET GLOBAL max_user_connections = 20;
- 若用户已存在，需显式重载权限才能让新限制起效：
FLUSH PRIVILEGES;
- 注意它和
GRANT ... WITH MAX_USER_CONNECTIONS的优先级：后者更细粒度，且会覆盖全局设置
如何给指定用户单独设连接上限
直接改全局 max_user_connections 是粗粒度方案，多数生产场景需要按用户分级控制，比如 API 用户限 50，DBA 账户不限，报表用户限 5。这时必须用 GRANT 语法绑定限制。
实操建议：
- 建用户或改权限时带上
MAX_USER_CONNECTIONS子句：GRANT SELECT ON mydb.* TO 'api_user'@'%' WITH MAX_USER_CONNECTIONS 50;
- 已有用户需先
REVOKE再GRANT才能更新限制，单纯ALTER USER不支持该参数 - 设为 0 表示不限（等同于全局
max_connections值），不是“禁止连接” - 执行后务必
FLUSH PRIVILEGES，否则新限制不会加载到内存权限表中
连接频率高 ≠ 连接数多，别混淆 rate limit 和 connection limit
用户频繁断连重连（比如每秒新建 10 个连接又立刻关闭），max_user_connections 完全无效——它只数“当前活着的连接”，不统计单位时间新建次数。这种场景下，你看到的是大量 sleep 状态连接残留，或应用报 Can't create more connections，但 SHOW STATUS LIKE 'Threads_connected' 却不高。
实操建议：
- 查真实并发连接数：
SELECT user, host, COUNT(*) FROM information_schema.processlist GROUP BY user, host;
- 看连接生命周期：重点关注
Time列是否长期 > 0，说明连接没被及时 close，大概率是应用没正确释放连接池资源 - MySQL 本身不提供连接频次限流（如每分钟最多 60 次），这类需求得靠中间件（如 ProxySQL 的
mysql-users表配max_connections+max_connect_errors组合）或应用层加令牌桶 - 检查客户端是否启用了
wait_timeout/interactive_timeout，太长会导致连接僵尸化
修改后不生效？重点检查这几个地方
设完 max_user_connections 或 GRANT ... WITH MAX_USER_CONNECTIONS，测试时发现限制没触发，八成掉进这几个坑里。
实操建议：
- 确认当前登录用户和
GRANT中的'user'@'host'完全一致，包括 host 是否用了%还是具体 IP，DNS 解析是否导致匹配失败 - 检查是否用了
--skip-grant-tables启动，此时权限系统被绕过，所有限制失效 - 如果用户是通过
CREATE USER ... IDENTIFIED WITH caching_sha2_password创建的，某些旧客户端可能因认证插件不兼容而走匿名用户逻辑，导致权限不匹配 - Percona Server 或 MariaDB 可能有额外限制项（如
max_statement_time），但标准 MySQL 不处理连接频次，别指望它替代应用层节流
最常被忽略的一点：MySQL 不记录连接建立失败的日志，默认关着 log_warnings = 2，所以你根本看不到“用户 X 被拒绝连接”的痕迹。要调试，得手动打开 general_log 或抓包看 TCP 层是否真被拒。
