MySQL创建用户时可用MAX_USER_CONNECTIONS限制其最大并发连接数，设为0表示不限制，非0值则严格限制；已有用户需用ALTER USER修改，不中断现有连接但新连接立即生效。
创建用户时直接设死最大连接数
MySQL 允许在 CREATE USER 语句里用 MAX_USER_CONNECTIONS 限制单个用户能同时建立多少个连接，这是最干净的起点控制方式。
注意：这个值只管“该用户从任意客户端发起的总连接数”，不管是不是同一个 IP 或应用进程。
- 设为
0表示不限制（默认值），不是“禁止连接” - 设为
10就是最多 10 个活跃连接，第 11 个会报错：Too many connections for user 'xxx' - 如果用户已存在，不能用
CREATE USER覆盖，得用ALTER USER
示例：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd123' MAX_USER_CONNECTIONS 5;
ALTER USER 修改已有用户的连接上限
线上用户不能删了重建，ALTER USER 是唯一安全的调整手段。它不会中断当前连接，但新连接会立即受新限制约束。
常见误操作：以为改完就立刻踢掉超限连接 —— 实际上 MySQL 不主动断连，只拦新连。旧连接得靠应用自己释放或等超时。
- 执行后需刷新权限：
FLUSH PRIVILEGES在 MySQL 8.0+ 通常不需要，但低版本（如 5.7）建议加上 - 如果设成
MAX_USER_CONNECTIONS 0，等于解除限制，不是禁用账号 - 多个资源限制（如
MAX_QUERIES_PER_HOUR）可以一起写，用空格分隔
示例：
ALTER USER 'report_user'@'10.%.%.%' MAX_USER_CONNECTIONS 3 MAX_QUERIES_PER_HOUR 1000;
查当前用户实际用了几个连接
MAX_USER_CONNECTIONS 是配额，但你得知道用户到底占了多少，否则没法判断是否真卡住了。
别看 SHOW PROCESSLIST —— 它只显示当前登录用户能看到的连接，权限受限时会漏。更可靠的是查 performance_schema。
- 必须确保
performance_schema已启用（默认开），且用户有SELECT权限 - 查询语句里要过滤
USER字段，注意格式是'username'@'host'，不是只写用户名 - 连接数统计不含 sleep 状态？错，
processlist表里所有状态都算，只要没断开就占一个名额
示例（查 app_user 当前用了几个连接）：
SELECT COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_USER = 'app_user';
MAX_USER_CONNECTIONS 和全局 max_connections 的关系
两者不叠加，也不互斥。一个是“每个用户最多连几个”，一个是“整个 MySQL 实例最多接受几个连接”。后者是硬上限，前者是软分配。
容易踩坑：把 MAX_USER_CONNECTIONS 设太高，结果所有用户加起来冲爆 max_connections，导致新用户连不上 —— 这时候报的错是 Too many connections（没提用户名），不是 Too many connections for user。
- 检查全局上限：
SHOW VARIABLES LIKE 'max_connections'; - 估算合理值：比如有 5 个业务用户，每个配 20，那
max_connections至少留出 120+ 余量给监控、备份、DBA 连接 - 连接数限制只对 TCP 连接生效，Unix socket 连接也计入（因为也是独立连接）
真正麻烦的点在于：限制生效是实时的，但连接释放依赖应用行为。很多 PHP-FPM 或 Java 连接池没正确 close，会导致配额长期被僵尸连接占着。
