MySQL不支持单用户总连接时长限制，仅提供空闲超时（wait_timeout）；需应用层记录首次连接时间并校验累计时长，数据库仅作资源兜底。

MySQL 怎么限制单个用户的总连接时长？

mysql 本身不支持「从登录开始计时、到点强制断开」的总时长控制——它只管空闲多久没动（wait_timeout），不管用户连了多久。所以如果你要实现“这个账号最多只能连 30 分钟”，得靠应用层配合，数据库只负责兜底。

常见错误现象：SET GLOBAL wait_timeout = 1800 后发现用户明明连了 40 分钟还没断；或者用连接池的应用，连接复用导致实际会话远超预期时间。

• wait_timeout 和 interactive_timeout 是空闲超时，不是总时长，且只对「无任何语句执行」的连接生效
• 一旦客户端发了新查询（哪怕只是 SELECT 1），倒计时就重置
• 连接池（如 HikariCP、Druid）会让连接长期复用，wait_timeout 基本失效
• 真正想控总时长，必须在应用里记录首次连接时间，并在每次请求前校验已用时长

GRANT WITH MAX_USER_CONNECTIONS 能不能当“时长限制”用？

不能。这是并发连接数限制，和时间完全无关。

使用场景：防某个 API 用户写死循环疯狂建连接，把 max_connections 打满；不是用来卡他“只能上半小时网”的。

• MAX_USER_CONNECTIONS 5 表示该用户最多同时有 5 个活跃连接，第 6 个会报错 Too many connections for user
• 设为 0 表示不限（不是禁止），优先级高于全局 max_user_connections
• 已有用户改限制必须 REVOKE + GRANT，ALTER USER 不支持该参数
• 修改后记得 FLUSH PRIVILEGES，否则权限表不更新

路由器或系统级怎么真正在“连接时长”维度做限制？

这类需求通常出现在访客 WiFi、网吧终端、学校机房等场景，需要的是“设备接入后 30 分钟自动踢下线”，这得靠网络设备或操作系统策略，不是数据库的事。

实操建议（以主流家用路由器为例）：

• 启用「访客网络」并单独设置 SSID，避免影响主网
• 在「家长控制」或「设备管理」里绑定设备 MAC 地址，再配置「每日可用时长 30 分钟」
• 注意有些路由器只支持「每天累计」而非「单次连续」，需确认策略类型
• 企业级设备（如 Cisco、FortiGate）可用 RADIUS + Session Timeout 属性实现更精细控制

为什么别指望数据库解决“上网时长”类问题？

因为数据库连接 ≠ 网络连接，也不等于用户在线状态。一个用户可能通过 Web 应用连着 MySQL，但自己早就锁屏走人了；也可能开着多个浏览器标签页，每个都维持着独立连接。

容易踩的坑：

• 把 wait_timeout 当成“用户在线时长”，结果家长以为孩子被踢下线了，其实只是数据库断了连接，前端还在静默续期 token
• 在 MySQL 层强行 kill 连接（KILL CONNECTION xxx）来模拟超时，但应用层无感知，很快又重连
• 混淆 max_user_connections 和连接频率限制（rate limit），后者需靠中间件或代理（如 ProxySQL、Cloudflare）实现

真要控时长，得从身份认证环节埋点，由业务服务统一维护会话生命周期——数据库只配好 wait_timeout 防资源滞留，就够了。