ALTER USER 是修改已有账号连接数的唯一可靠方式，仅修改 MAX_USER_CONNECTIONS 字段且立即生效；新账号须在 CREATE USER 或 GRANT 时显式使用 WITH 关键字设定限制；验证需查 mysql.user 表及实测超限行为。
ALTER USER 是修改已有账号连接数的唯一可靠方式
生产环境里，绝大多数需求是给已存在的账号加限制，ALTER USER 是唯一推荐操作。它只改 MAX_USER_CONNECTIONS 字段，不碰权限、密码或 SSL 设置，且 MySQL 8.0+ 执行后立即生效，无需 FLUSH PRIVILEGES。
-
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 8;—— 必须写全用户名和 host，'app_user'@'localhost'和'app_user'@'127.0.0.1'是两个独立账号，需分别执行 - 设为
0表示不限制（退回到全局max_connections约束），线上账号不建议留0 -
SET GLOBAL max_user_connections = 5完全无效——它只影响后续新建用户的默认值，对已有账号毫无作用
CREATE USER 或 GRANT 创建新账号时必须显式带 WITH
新账号务必在创建阶段就定死连接上限，避免后期疏漏。语法细节决定是否真生效，漏写 WITH 或版本不匹配会导致静默失败。
- MySQL 8.0.16+：直接用
CREATE USER 'api_user'@'%' IDENTIFIED BY 'xxx' WITH MAX_USER_CONNECTIONS 20; - MySQL 5.7 兼容写法：先
CREATE USER，再GRANT USAGE ON *.* TO 'api_user'@'%' WITH MAX_USER_CONNECTIONS 20;（USAGE不授任何权限，只设资源限制） - 错误示范：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'xxx' MAX_USER_CONNECTIONS 20;—— 缺WITH关键字，语句可能不报错但限制不生效
验证是否真生效？别信 SHOW GRANTS，要查表 + 实测
SHOW GRANTS 根本不显示 MAX_USER_CONNECTIONS，因为它不是权限，而是用户元数据属性。配置写没写进系统表、限制有没有触发，必须分两步验证。
- 查配置是否落库：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';—— 返回值必须是你设的整数，不是0或NULL - 查实时占用数（需开启
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;"并发开第 N+1 个连接（N 是你设的上限），应明确报错ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections'
连接池配置必须 ≤ 数据库账号限制值
限制生效后，旧连接不会被踢，应用侧若没正确释放连接，SHOW PROCESSLIST 看到的连接数会远超设定值——这不是配置失效，而是连接堆积。真正起作用的，是第 N+1 次新建连接被拒绝。
- HikariCP、Druid 等连接池的
maximumPoolSize必须 ≤ 账号的MAX_USER_CONNECTIONS值，否则启动或压测时必然部分连接失败 - PHP 使用
PDO::ATTR_PERSISTENT => true或 Laravel 默认连接池时，连接不会随脚本结束释放，容易提前占满配额 - 连接处于
Sleep状态但未超wait_timeout，仍被计入配额；异常中断后未清理（如网络闪断），也会卡住名额
真实生效的关键点不在语法对不对，而在应用是否主动断开连接、连接池是否配置得当、以及你查的是不是 mysql.user 表里的实际值——这三个地方，任何一个出问题，限制就形同虚设。
