MySQL通过MAX_USER_CONNECTIONS可按用户限制并发连接数，建用户时用CREATE USER或已有用户用ALTER USER设置，设为0表示不限制；它与全局max_connections协同生效，用于精准控流而非全局资源控制。
MySQL 限制单用户并发连接数：直接设 MAX_USER_CONNECTIONS
MySQL 原生支持按用户粒度限制最大同时连接数，核心就是 MAX_USER_CONNECTIONS 这个账户级限制。它不依赖应用层或中间件，生效在连接认证阶段——用户一连就校验，超了直接报错 ER_USER_LIMIT_REACHED。
实操上只有两条路：建用户时指定，或对已有用户修改。注意这不是全局变量，不能通过 SET GLOBAL 调整，必须走 CREATE USER 或 ALTER USER。
CREATE USER 'app_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_USER_CONNECTIONS 5;ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 3;- 设为
0表示不限制（默认值），不是“禁止连接”
为什么 max_connections 全局配置不管用？
max_connections 是整个 MySQL 实例能接受的最大连接总数，所有用户共享。它解决的是服务器资源过载问题，不是某个业务账号的连接滥用问题。比如你有 10 个应用用户，每个都开 50 个连接，max_connections=200 很快就占满，但你没法知道是哪个用户拖垮的。
MAX_USER_CONNECTIONS 才是精准控流的关键——它让每个用户在连接池、重试逻辑失控时，不至于把整个实例拖死。常见于微服务里多个实例共用一个数据库账号的场景。
- 全局
max_connections影响内存占用和文件描述符数量 -
MAX_USER_CONNECTIONS不消耗额外内存，只在握手时做一次整数比对 - 两者叠加生效：用户连接数 ≤ 自身限制，且所有连接总数 ≤
max_connections
遇到 ER_USER_LIMIT_REACHED 错误怎么确认原因？
客户端报错类似：User 'app_user' has exceeded the 'max_user_connections' resource (current value: 5)。别急着调高数值，先查清楚是不是连接没释放。
登录 MySQL 后执行：SELECT user, host, max_user_connections FROM mysql.user WHERE user = 'app_user'; 确认当前限制值；再用 SHOW PROCESSLIST; 看该用户当前活跃连接有哪些、持续时间多长、状态是不是 Sleep。
- 大量
Sleep连接说明应用没正确 close 或连接池配置过松 - 连接数卡在限制值附近波动，大概率是连接泄漏，不是配小了
-
MAX_USER_CONNECTIONS对 SUPER 权限用户无效，但普通账号即使有PROCESS权限也受限制
应用侧配合要点：别让限制变成雪崩起点
单纯在 DB 层设限，如果应用没适配，可能把错误放大。比如连接池配置了 minIdle=10，但 DB 只给 5 个连接，启动时就会卡住或反复重试失败。
关键是对齐：连接池最大连接数 ≤ DB 设置的 MAX_USER_CONNECTIONS，并预留 1–2 个余量防瞬时尖峰。还要确保连接获取超时、失败重试策略合理，避免线程卡死。
- HikariCP：设
maximumPoolSize≤ DB 侧限制值 - Druid：对应
maxActive，同样需向下对齐 - Spring Boot 2.5+ 默认 Hikari，注意
spring.datasource.hikari.maximum-pool-size配置
真正容易被忽略的是监控联动——光设了限制没用，得把 SHOW PROCESSLIST 结果或 performance_schema.threads 中的用户连接数打点进监控系统，否则等报警时已经晚了。
