MySQL中不存在MAX_CONNECTION配置项，正确限制单个账号连接超时需用CREATE/ALTER USER指定WAIT_TIMEOUT；max_user_connections仅限并发数，非超时机制。
MySQL 里没有 MAX_CONNECTION 这个配置项，也不能靠它来限制单个应用账号的连接超时——这是个常见误解，直接设了会报错或无效。
为什么 MAX_CONNECTION 不是合法配置？
MySQL 官方配置项中根本不存在 MAX_CONNECTION。你可能混淆了以下三个东西：
-
max_connections：全局最大并发连接数，影响所有用户，不是 per-account 的 -
max_user_connections：可限制单个账号的**同时活跃连接数**（注意：不是超时） -
wait_timeout/interactive_timeout：控制空闲连接自动断开的时间，但默认对所有用户统一生效，需配合账号级变量设置
试图在 my.cnf 或 SET GLOBAL 里写 MAX_CONNECTION，MySQL 会直接拒绝启动或返回 Unknown system variable 错误。
怎么真正给某个应用账号设连接空闲超时？
MySQL 5.7.6+ 支持为账号单独指定 wait_timeout，前提是用 CREATE USER 或 ALTER USER 显式声明。旧版本只能靠应用层或中间件兜底。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 创建账号时指定：
CREATE USER 'app_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_USER_CONNECTIONS 10 WAIT_TIMEOUT 60;
- 修改已有账号：
ALTER USER 'app_user'@'%' WITH WAIT_TIMEOUT 60;
- 验证是否生效：
SELECT user, host, max_user_connections, password_last_changed FROM mysql.user WHERE user = 'app_user';
（注意：wait_timeout不存于mysql.user表，需登录后执行SHOW VARIABLES LIKE 'wait_timeout';确认）
这个 WAIT_TIMEOUT 60 表示该账号建立的连接，如果连续 60 秒没发任何语句，服务端就会主动断开。不适用于长连接保活场景（比如带心跳的应用），也不影响正在执行的查询。
为什么 max_user_connections 常被误当成“超时”？
因为很多应用出错时看到 Too many connections，第一反应是“连接没释放”，于是想“限制它最多连几个”——但这只是堵漏，不是治本。
-
max_user_connections 5意味着该账号最多维持 5 个活跃连接，第 6 次CONNECT就会失败，报错User 'app_user' has already more than '5' active connections - 它不清理旧连接，也不触发超时；如果应用不 close，这 5 个连接可能一直挂着，直到触发全局
wait_timeout - 线上调低这个值要小心：连接池配置（如 HikariCP 的
maximumPoolSize）必须 ≤ 它，否则启动就卡住
容易被忽略的关键点
账号级 WAIT_TIMEOUT 只在用户登录时读取一次，后续 session 内不可被 SET SESSION wait_timeout = ... 覆盖（除非显式再 set，但不推荐）。更麻烦的是：
- PHP PDO、Python MySQLdb 等驱动默认启用
AUTOCOMMIT=0，且可能复用连接但不清除 session 变量，导致超时行为不一致 - Docker 或云数据库（如阿里云 RDS）常覆盖底层配置，
ALTER USER设的值可能被运维策略重置，上线前务必连上去SHOW VARIABLES实测 - 如果你用的是 ProxySQL 或 MaxScale，超时逻辑可能被代理层接管，MySQL 侧的设置就失效了
真要稳，得在应用代码里显式设置连接生命周期，比如 Go 的 db.SetConnMaxLifetime(5 * time.Minute)，比只靠 MySQL 配置靠谱得多。
