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 防资源滞留，就够了。
