ALTER USER修改用户连接数最常用稳妥，仅限新连接生效；CREATE USER可创建时设限；验证需模拟超限；全局max_user_connections慎用，推荐逐用户设置。
直接用 ALTER USER 修改已有用户连接数
最常用、最稳妥的方式就是对已存在的用户执行 ALTER USER 命令，指定 MAX_USER_CONNECTIONS。它不改变权限，只加限制，且立即生效（新连接受控）。
- 示例：把用户
'app_user'@'%'的并发连接上限设为 8：ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 8;
- 如果用户是本地账号（
'app_user'@'localhost'），主机名必须完全匹配，否则会报错ERROR 1396 (HY000): Operation ALTER USER failed... - 设为
0表示不限制（MySQL 默认值），不是“禁止连接”——这点常被误解 - 修改后无需
FLUSH PRIVILEGES（ALTER USER自动刷新），但旧连接仍保持活跃，限制只作用于后续新建连接
创建用户时就带上连接限制，避免后期补救
在部署阶段就固化资源策略，比上线后再调整更安全。用 CREATE USER 语句一次性声明连接上限，逻辑清晰、不易遗漏。
- 语法注意：
MAX_USER_CONNECTIONS是子句，不是字段，不能写成IDENTIFIED BY 'pwd' MAX_USER_CONNECTIONS 5（缺WITH）；正确写法是：CREATE USER 'dev_user'@'10.0.2.%' IDENTIFIED BY 's3cr3t' WITH MAX_USER_CONNECTIONS 5;
- 若创建时漏了限制，后续只能靠
ALTER USER补上——没有“创建+限制”的原子操作 - 配合
GRANT分权：先建用户限连接，再单独授库表权限，职责分离更可控
验证是否真的生效？别只看 mysql.user 表
SELECT ... FROM mysql.user 只显示配置值，不代表运行时实际拦截有效。真正要确认，得模拟超限并观察行为。
- 查配置：
SELECT User, Host, Max_user_connections FROM mysql.user WHERE User = 'app_user';
- 查实时连接数（需开启
performance_schema）：SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app_user' GROUP BY user;
- 触发验证：用脚本或工具（如
mysql -u app_user -p -e "SELECT 1;"）开第 9 个连接（假设限制为 8），应收到明确报错：ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource limit - 常见误判：应用用了连接池，一个服务进程可能持有多条连接，容易误以为“没超限”，其实已悄悄占满配额
全局 max_user_connections 是默认兜底，慎用
这个变量设的是“所有未显式设置 MAX_USER_CONNECTIONS 的用户的默认上限”，不是总开关。设得太低会影响所有新用户，设太高又失去意义。
- 查看当前值：
SHOW VARIABLES LIKE 'max_user_connections';
默认是0（无限制），改之前先确认业务是否真需要统一兜底 - 临时设为 10：
SET GLOBAL max_user_connections = 10;
但重启即失效；永久设置需写入my.cnf的[mysqld]段 - 风险点：一旦设了非零值，所有新用户（包括运维账号）都会继承该限制，除非显式覆盖——线上环境曾因此导致 DBA 连不上库排障
- 推荐做法：只对业务用户逐个设限，全局值保持
0，更透明、更易追踪
wait_timeout 缩短空闲连接生命周期，并确保应用端连接池配置（如 maxActive）不超过数据库侧的配额——两边不匹配，才是线上连接耗尽最常见的根因。 
