MySQL中设置单个用户最大连接数应使用ALTER USER（5.7+）或GRANT USAGE（5.6及更早）配合MAX_USER_CONNECTIONS，无需重启；设为0表示不限制，-1表示未设置；超限时报ERROR 1203。
MySQL 中如何设置单个用户的最大连接数
直接通过 GRANT 语句或 ALTER USER 设置 MAX_USER_CONNECTIONS 即可生效，无需重启 MySQL。这是最常用也最安全的限制方式，比全局 max_connections 更精准。
常见错误是误以为修改 my.cnf 中的全局配置能限制某个用户——其实不能，max_connections 控制的是整个实例的总连接上限，和用户粒度无关。
- MySQL 5.7+ 推荐用
ALTER USER 'user'@'host' WITH MAX_USER_CONNECTIONS N - MySQL 5.6 或旧版本需用
GRANT USAGE ON *.* TO 'user'@'host' WITH MAX_USER_CONNECTIONS N（注意：USAGE不授予权限，仅设资源限制） - 设为
0表示不限制（等同于未设置），不是“禁止连接” - 执行后需
FLUSH PRIVILEGES（仅 5.6 及更早版本需要；5.7+ 自动刷新）
查看当前用户的 MAX_USER_CONNECTIONS 设置
权限限制不会直接显示在 SHOW GRANTS 结果里，必须查系统表或用专用语句。
推荐查 mysql.user 表（需有 SELECT 权限）：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'your_user';
或者用更直观的方式（MySQL 8.0+）：
SELECT * FROM performance_schema.accounts WHERE USER = 'your_user'\G
注意：performance_schema.accounts 中的 CURRENT_CONNECTIONS 和 TOTAL_CONNECTIONS 是运行时统计，不等于限制值。
-
max_user_connections = -1在mysql.user表中表示“未显式设置”，实际行为等同于 0（即不限） - 如果查不到该用户记录，说明从未设置过，走默认不限制逻辑
- 普通用户无法查自己或他人的限制值，只有
SUPER或SELECT ON mysql.*权限才行
连接数超限后的真实表现与排查方法
用户连接被拒时，客户端收到的错误是：ERROR 1203 (42000): User user_name already has more than 'max_user_connections' active connections。这不是网络或认证失败，而是明确的资源拒绝。
容易踩的坑是把问题归因为连接没关闭、连接池泄漏，其实只是配得太紧。
- 超限连接尝试会立即失败，不会排队或等待
- 已建立的连接不受影响，限制只作用于新建连接
- 若应用使用连接池（如 HikariCP），需确认
maximumPoolSize≤ 用户的MAX_USER_CONNECTIONS，否则启动就报错 - 临时排查可用
SHOW PROCESSLIST统计某用户当前活跃连接：SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE USER = 'your_user'
和 wait_timeout / interactive_timeout 的关键区别
MAX_USER_CONNECTIONS 管“能连几个”，wait_timeout 管“连上后闲多久断”。两者完全正交，常被混淆。
典型误操作：调小 wait_timeout 以为能缓解连接堆积，结果只是让空闲连接更快断开，但并发建连请求仍可能瞬间打满限额。
-
wait_timeout默认 28800 秒（8 小时），对长连接友好；短连接场景建议设为 30–300 秒 -
MAX_USER_CONNECTIONS是硬上限，无超时缓冲，适合做服务级隔离（比如给监控账号设为 3，给 API 服务设为 50） - 二者同时配置才完整：既防滥用建连，又防连接长期空挂
真正难处理的是连接复用不充分的老旧应用——它可能每秒建十几个连接却只用几毫秒，这时光靠 MAX_USER_CONNECTIONS 拦不住，得配合应用层连接池或代理层限流。
