直接用 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，更透明、更易追踪 MySQL 用户连接限制本质是资源隔离手段，不是安全围栏。它防不住恶意查询，也拦不住长事务，真正关键的是结合
wait_timeout缩短空闲连接生命周期，并确保应用端连接池配置（如
maxActive）不超过数据库侧的配额——两边不匹配，才是线上连接耗尽最常见的根因。
