mysql 5.7+ 必须用 create user 或 alter user 显式设置资源限制，grant 不生效；最关键是 max_user_connections，用于防止连接泄露拖垮服务，设为0表示不限制，生产环境严禁；角色不继承资源限制，需逐用户配置。
MySQL 5.7+ 如何用 CREATE USER 或 ALTER USER 设置资源限制
MySQL 原生支持对单个用户做 CPU、连接数、查询次数等硬性配额，但仅限于 5.7 及以上版本（8.0 更稳定），且必须用 CREATE USER 或 ALTER USER 显式声明，GRANT 不会覆盖或追加这些限制。
常见错误是以为给用户授了权限就自动受控，其实不设配额等于不限制——哪怕只给了 SELECT 权限，该用户也能发起海量慢查询拖垮服务器。
-
MAX_QUERIES_PER_HOUR n：每小时最多执行n条语句（含SELECT、INSERT等所有语句） -
MAX_UPDATES_PER_HOUR n：仅限制修改类语句（UPDATE/DELETE/INSERT），不影响SELECT -
MAX_CONNECTIONS_PER_HOUR n：每小时最多新建n个连接（不是并发连接数） -
MAX_USER_CONNECTIONS n：该用户**同时存活**的最大连接数（最常用、最有效）
示例：
CREATE USER 'app_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_USER_CONNECTIONS 5;注意：如果用户已存在，必须用
ALTER USER，不能重复 CREATE USER。
为什么 MAX_USER_CONNECTIONS 是最关键的限制项
多数业务卡顿源于某个应用泄露连接（比如没 close()、连接池配置过大），导致 MySQL 的 Threads_connected 持续攀升，最终耗尽 max_connections，其他合法用户全被拒绝。此时 MAX_USER_CONNECTIONS 能直接掐断源头。
它和全局 max_connections 的关系是“包含”而非“叠加”：一个用户最多连 n 个，不管其他用户剩多少额度；但总连接数仍不能超全局上限。
- 设为
0表示不限制（默认值），生产环境切勿保留此值 - 值太小会导致正常业务报错
Too many connections（注意这不是全局错误，而是该用户专属） - MySQL 不会自动 kill 超限的新连接，而是直接拒绝，所以应用层需处理
ER_CON_COUNT_ERROR错误码
MySQL 8.0 中角色（ROLE）能否继承资源限制
不能。MySQL 的角色（CREATE ROLE）只继承权限（GRANT），不继承任何资源限制。即使把一个带 MAX_USER_CONNECTIONS 3 的用户 GRANT 给角色，再把角色赋给另一个用户，后者依然不受该限制约束。
这意味着：资源配额必须按用户粒度单独设置，无法批量管理。自动化运维时得遍历 mysql.user 表，用脚本生成 ALTER USER ... WITH ... 语句。
- 查当前用户的限制：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'xxx'; - 修改后必须执行
FLUSH PRIVILEGES;才生效（8.0.16+ 可省略，但建议显式执行） - 限制变更**不中断已有连接**，只影响后续新连接
监控与告警：如何发现配额被触发
MySQL 自身不记录“因配额拒绝连接”的日志，默认关闭 general_log 和 slow_query_log 时，这类拒绝是静默的。应用只会收到类似 Host 'x.x.x.x' is blocked because of many connection errors 的误导信息（其实是配额问题，不是连接错误）。
- 关键指标：观察
SHOW STATUS LIKE 'Aborted_connects';上升是否伴随应用报错，但该值也包含密码错误等干扰项 - 更准的方式：在应用侧捕获连接失败时的错误信息，匹配
ER_CON_COUNT_ERROR（错误号 1203）或字符串"Too many connections"（注意区分全局超限） - Percona Server 或 MariaDB 提供
user_statistics表可查各用户实际连接/查询计数，官方 MySQL 不支持实时统计
真正难的是定位“哪个用户配额设低了”，而不是“怎么设”。线上调参永远要留余量——比如预估峰值 8 个连接，先设 15，跑一周看监控再压到 10。
