alter user是唯一真正生效的设置方式，必须用alter user 'user'@'host' with max_user_connections n显式配置，设为0表示不限制（退回到全局max_connections），修改后立即生效且需通过mysql.user表和新连接实测验证。
ALTER USER 是唯一能真正生效的设置方式
直接改 max_connections 或执行 SET GLOBAL max_user_connections = N 对已有用户完全无效——前者控制实例总连接数，后者只影响后续新用户的默认值。真正起作用的是每个账号在 mysql.user 表中独立存储的 Max_user_connections 字段，必须用 ALTER USER 显式写入。
常见错误包括：
- 把
'app_user'@'192.168.%'和'app_user'@'localhost'当成同一个账号，其实它们是两条独立记录，必须分别执行ALTER USER - 误以为设为
0是“禁止连接”，实际是退回到全局max_connections约束，线上环境应避免留0 - MySQL 8.0+ 不再支持直接 UPDATE
mysql.user表，硬改会报错Unknown column 'max_user_connections' in 'field list'
新建用户时必须绑定 MAX_USER_CONNECTIONS
部署阶段就固化限制，比事后补救更可靠。CREATE USER 语句里必须显式带 WITH MAX_USER_CONNECTIONS 子句，且位置不能错——它必须紧跟在 IDENTIFIED BY 后面，不能放到末尾或单独成句。
正确写法示例：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'xxx' WITH MAX_USER_CONNECTIONS 15;
错误写法（会报语法错误）：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'xxx'; -- 缺少 WITH 子句 GRANT USAGE ON *.* TO 'api_user'@'%' WITH MAX_USER_CONNECTIONS 15; -- GRANT 不支持该子句（5.7+）
注意：MySQL 5.7.6+ 才支持此语法；5.6 及更早版本只能用 GRANT USAGE ... WITH MAX_USER_CONNECTIONS，且需配合 FLUSH PRIVILEGES。
验证配置是否真生效，不能只查 mysql.user
查 SELECT User, Host, Max_user_connections FROM mysql.user WHERE User = 'xxx'; 只确认配置写入成功，不代表运行时拦截有效。关键要看两点：
- 当前活跃连接数：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'xxx' GROUP BY user;—— 这个值才是实时计数依据 - 超限行为是否触发：
mysql -u xxx -p -e "SELECT 1;"并发执行，第N+1次（N 是你设的上限）应立即报错ERROR 1226 (42000): User 'xxx' has exceeded the 'max_user_connections' resource
特别注意：SHOW PROCESSLIST 显示的是已建立连接，而限制只在校验新建连接握手阶段触发。所以看到连接数超限 ≠ 配置失效，很可能是旧连接未释放或连接池未回收。
连接池配置必须 ≤ 用户限制值
应用层若用 HikariCP、Druid 等连接池，其 maximumPoolSize（或等效参数）必须 ≤ 对应账号的 MAX_USER_CONNECTIONS 值。否则启动或压测时必然触发拒绝连接，且连接池不会自动降级或重试。
容易被忽略的点：
- 多个微服务共用同一账号（如
'app'@'%'），但各自配了maximumPoolSize=20，总连接数轻松突破 100 - 连接池配置了
minIdle，即使没流量也会维持固定数量空闲连接，全计入配额 - 连接处于
Sleep状态但未超wait_timeout，仍被算作活跃连接
真实风险从来不在连接数本身，而在连接背后那条没加 LIMIT 的全表扫描，或没索引的 WHERE 条件——连接数限制只是第一道隔离墙，后面还得跟内存监控和查询熔断。
