单用户并发连接无法耗尽全局资源但可占满max_connections，关键在于未设置MAX_USER_CONNECTIONS；需用ALTER USER显式限制，并配合调低wait_timeout与连接池超时参数。
直接结论：单用户并发连接不可能“占满”全局资源，但能轻易耗尽 max_connections，关键在于是否设置了 MAX_USER_CONNECTIONS。
为什么单用户能拖垮整个 MySQL 实例
一个用户开 100 个长连接，其他用户就可能连不上——这不是 bug，是默认行为。MySQL 8.0 的 max_connections 是全局共享池，所有用户共用；而 MAX_USER_CONNECTIONS 默认为 0（不限制），等于放行所有连接请求，直到总连接数触顶。
此时报错是标准的 ERROR 1040 (HY000): Too many connections，服务层面已不可用，但你查不到具体是哪个用户干的。
- 没有
MAX_USER_CONNECTIONS限制的用户，连接数只受max_connections总量约束 - 连接池（如 HikariCP）默认
maximumPoolSize=10，一个微服务就能悄悄占掉 10 个 slot -
wait_timeout默认 28800 秒，Sleep 连接长期不释放，Threads_connected持续高位
必须用 ALTER USER 显式设置 MAX_USER_CONNECTIONS
这是唯一可靠、立即生效、无需重启的方式。CREATE USER 里写 WITH MAX_USER_CONNECTIONS 5 在 MySQL 8.0.16+ 才真正有效，旧版本会被忽略；GRANT 语句虽兼容，但容易和权限混淆，不推荐。
正确操作：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 8;
注意点：
- 主机名必须完全匹配，
'app_user'@'localhost'和'app_user'@'127.0.0.1'是两个独立账户，需分别设限 - 设为 0 表示取消该用户的限制（退回到全局约束），生产环境严禁留 0
- 修改后旧连接不受影响，只约束后续新建连接
验证限制是否真起作用，不能只看 mysql.user 表
查 mysql.user 只确认配置写入成功，不代表运行时拦截有效。必须结合实时连接状态判断：
查当前活跃连接数（排除 Sleep）：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app_user' GROUP BY user;
查配额是否加载：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';
手动触发验证：
- 用该账号开 8 个
mysql -u app_user -p -e "SELECT 1;"终端 - 第 9 次应明确报错：
ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource limit - 如果没报错，大概率是 host 不匹配或用了连接池缓存连接
配套调低 wait_timeout + 连接池 idle_timeout
只设 MAX_USER_CONNECTIONS = 1 还可能失败——因为应用未 close()，连接变成 Sleep 堆在那儿，新连接仍被拒绝。
必须组合调整：
- 把
wait_timeout改为 300（5 分钟），让空闲连接自动断开 - HikariCP 中设
idleTimeout=300000、maxLifetime=1800000，避免连接长期滞留 - 禁用
autoReconnect=true，它会导致重连风暴，触发MAX_CONNECTIONS_PER_HOUR误判
真正难控的不是连接上限本身，而是应用层对连接生命周期的管理意识。数据库配额只是最后一道闸门，关得再紧，上游持续漏水也没用。
