alter user 是 mysql 8.0 中唯一可靠、立即生效且不重启即可设置 max_user_connections 的方式；需用 with 关键字显式绑定，@'host' 必须与 show grants 输出一致，设为 0 表示不限制但线上不建议；grant usage 可安全仅限连接数；验证需查 mysql.user 表和 performance_schema.threads；应用连接池配置不得超过该限制，多服务共用账号时应拆分；还需配合 wait_timeout 防止空闲连接占满限额。
直接用 ALTER USER 设置 MAX_USER_CONNECTIONS，这是 MySQL 8.0 中唯一可靠、立即生效且不重启的方式；SET GLOBAL max_user_connections 对已有用户完全无效，别被名字误导。
ALTER USER 是修改已有用户的唯一推荐方式
生产环境里账号早就存在，不能删了重建。这时候必须用 ALTER USER 显式绑定限制：
-
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 15;—— 注意WITH关键字不能省，@'host'必须和SHOW GRANTS FOR 'app_user'@'host'输出完全一致 - 如果该用户还配了
'app_user'@'localhost'，得再执行一遍：ALTER USER 'app_user'@'localhost' WITH MAX_USER_CONNECTIONS 5;，MySQL 把它们当两个独立账户 - 设为
0表示不限制（退回到全局max_connections），线上不建议留0 - MySQL 8.0+ 自动刷新权限缓存，
FLUSH PRIVILEGES不需要
GRANT USAGE 是只改连接数不碰权限的安全写法
当你只想调连接上限、但不想动已有权限或密码时，GRANT USAGE 最干净：
-
GRANT USAGE ON *.* TO 'report_user'@'10.0.0.%' WITH MAX_USER_CONNECTIONS 3;——USAGE表示“啥权限都不给”，只用来设资源限制 - 它兼容 MySQL 5.7 及以上，比
CREATE USER ... WITH MAX_USER_CONNECTIONS更稳妥（后者在 8.0.16 前不支持） - 不能写成
CREATE USER 'xxx'@'%' IDENTIFIED BY 'pwd' WITH MAX_USER_CONNECTIONS 5;，老版本会直接报错
验证是否真生效，只看两个地方
改完命令没报错 ≠ 生效。必须交叉验证配置值和实时连接行为：
- 查系统表确认写入：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';—— 字段名是全小写max_user_connections，不是大写或驼峰 - 查当前活跃连接数：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app_user';—— 这个COUNT就是当前真正占着的连接数 - 手动触发测试：开 3 个终端，并行执行
mysql -u app_user -p -e "SELECT 1;"，第 4 次应明确报错：ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource (current value: 3)
连接池配置必须 ≤ 用户限制值
这是最容易被忽略的落地环节。应用层的连接池如果设得比数据库用户限制还高，一启动就失败：
- HikariCP 的
maximumPoolSize、Druid 的maxActive，必须 ≤ 对应账号的MAX_USER_CONNECTIONS值 - 多个微服务共用同一账号（如
'app'@'%'）时，总连接数会叠加突破限制——建议按实例拆分账号，比如'app_web1'@'10.0.1.10'和'app_api'@'10.0.1.11' - 空闲连接不释放？光设
MAX_USER_CONNECTIONS不够，还得配wait_timeout让长期 Sleep 的连接自动断开，否则 20 个连接全挂着，新请求照样进不来
