max_user_connections只限制新连接建立，不终止已有连接；ALTER USER必须带WITH关键字且User@Host完全匹配；验证需查mysql.user表max_user_connections字段；连接池配置超限必报错1226。
max_user_connections只拦新连，不杀旧连
设置MAX_USER_CONNECTIONS后连接数还是飙高，最常见原因是它根本不管已存在的连接。哪怕你给'app'@'192.168.1.100'设了限制为5，只要这5个连接早就在那儿了，它们就能一直活着、发查询、占内存——限制只在第6次mysql -u app -p时才触发报错ERROR 1226 (42000)。
所以SHOW PROCESSLIST里看到20个Sleep状态的app用户连接，完全不矛盾；真正该查的是performance_schema.threads里实时前台连接数：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'app';
ALTER USER没生效？检查User@Host和WITH关键字
执行ALTER USER 'app'@'%' MAX_USER_CONNECTIONS 5不会报错，但大概率没生效——语法缺WITH关键字，MySQL会静默忽略。正确写法必须是：ALTER USER 'app'@'%' WITH MAX_USER_CONNECTIONS 5。
更隐蔽的坑是User@Host必须逐字匹配：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 账号实际是
'app'@'192.168.1.100'，你改'app'@'%'或'app'@'localhost'都无效 - 验证唯一可靠方式是查表：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app';，字段名是全小写max_user_connections，值为NULL表示未设置
连接池配置 > 用户限制 = 必炸
数据库侧设了MAX_USER_CONNECTIONS 5，但应用端HikariCP的maximumPoolSize配成10，启动瞬间就会反复报ERROR 1226。连接池不会自动降级，也不会等空闲连接释放——它会一股脑尝试建满10个连接，前5个成功，后5个全被MySQL拒绝。
多个服务共用同一账号（比如所有微服务都用'app'@'%'）时，连接数是叠加计算的。一个实例建5个，三个实例就直接冲到15，远超限制。解决办法不是调大限制，而是拆账号：'app_web1'@'10.0.1.10'、'app_api2'@'10.0.1.11'。
空闲连接不释放，配额就卡死
即使应用代码写了connection.close()，如果连接池的idleTimeout设得比MySQL的wait_timeout还长，连接在池子里“睡着”却没被MySQL主动断开，就会一直占着配额。比如MySQL设了wait_timeout = 60，而HikariCP的idleTimeout = 300000（5分钟），那连接在池里最多活5分钟，但第61秒MySQL就已把它当僵尸断开了，池子却还傻等。
关键参数要对齐：
- MySQL侧：统一设
wait_timeout = interactive_timeout = 600（10分钟） - HikariCP侧：
idleTimeout必须小于它，推荐600000（10分钟）或更低；keepaliveTime设300000定期探测 - 别漏掉
skip_name_resolve = ON，DNS反查失败会导致连接卡在unauthenticated user状态，白占配额
