ALL权限用户未设MAX_USER_CONNECTIONS会导致其独占全部连接，引发连接池爆满；需通过查询mysql.user、SHOW PROCESSLIST及information_schema.PROCESSLIST定位滥用账号，并用CREATE/ALTER USER或GRANT USAGE限制单用户连接数，同时协同调整应用端连接池参数。
为什么 ALL 权限用户会导致连接池爆满
MySQL 的 max_connections 是全局上限，但每个用户还能被单独限制——如果给业务用户授予了 ALL PRIVILEGES 却没设 MAX_USER_CONNECTIONS，等于放任该用户独占全部连接。更糟的是，有些应用用一个账号跑所有服务（比如 Spring Boot 全局 datasource 配置），一旦这个账号下的某条线程卡住、泄漏或慢查询堆积，就会迅速吃光池中连接，而其他用户（包括 DBA）可能连 SHOW PROCESSLIST 都执行不了。
如何快速定位高权限账号滥用连接
登录 MySQL 后立即查三件事：
-
SELECT user, host, max_user_connections FROM mysql.user WHERE max_user_connections = 0 OR max_user_connections > 100;——0表示不限制，极危险 -
SHOW PROCESSLIST;看User列是否集中出现在某几个账号下，尤其注意状态为Sleep或Cleaning up且持续超 300 秒的连接 -
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE USER = 'app_user';替换为疑似账号，确认其实际占用数是否接近max_connections
限制单用户连接数的两种安全写法
不要直接改 mysql.user 表，用授权语句才生效：
- 新建用户时就加限制：
CREATE USER 'app_rw'@'10.20.%' IDENTIFIED BY 'pwd' WITH MAX_USER_CONNECTIONS 30; - 已有用户追加限制：
ALTER USER 'app_ro'@'%' WITH MAX_USER_CONNECTIONS 15; - 若必须保留旧账号，可先回收再重授：
GRANT USAGE ON *.* TO 'legacy_app'@'%' WITH MAX_USER_CONNECTIONS 20;
注意：FLUSH PRIVILEGES 不需要执行，ALTER USER 和 GRANT USAGE 会即时生效。
配合连接池配置避免“权限宽松 + 池子激进”组合拳
即使限制了单用户连接数，如果应用侧连接池（如 Druid）的 max-active 设置过高，仍可能在短时间内打满该用户的额度。典型错误配置：
- 数据库端允许单用户最多 50 连接，但 Druid 配了
spring.datasource.druid.max-active=100→ 必然报错 - Druid 的
min-idle=20且应用启动即预热 → 一上来就占掉用户配额一半 - 未启用
remove-abandoned-on-borrow=true，导致连接泄漏后无法自动回收
建议比例：Druid 的 max-active ≤ 数据库侧该用户的 MAX_USER_CONNECTIONS × 0.7，留出缓冲给管理连接和临时排查窗口。
真正容易被忽略的是：权限限制和连接池参数必须协同调整，而不是只改一边。很多团队调大了 max_connections 却忘了同步收紧 MAX_USER_CONNECTIONS，结果只是把爆满时间推迟了几小时，问题本质没变。
