MySQL 8.0 不支持按用户粒度设置会话闲置超时，wait_timeout 和 interactive_timeout 仅为全局或会话级参数；需通过配置文件永久修改、连接池探活协同及应用/代理层拦截等间接手段实现用户级限制。
MySQL 8.0 本身不支持按用户粒度设置会话闲置超时——wait_timeout 和 interactive_timeout 是全局或会话级参数，无法针对某个 'user'@'host' 单独配置。所谓“限制某用户”，只能通过间接手段实现，且必须明确：这不是数据库原生能力，而是组合策略。
查清当前生效的 timeout 值，别信默认值
不同环境实际值差异极大：本地 MySQL 默认常为 28800 秒（8 小时），阿里云 RDS 可能是 300 秒（5 分钟），AWS RDS 强制最小 60 秒且禁止修改。连上库后立刻执行：
SELECT @@wait_timeout, @@interactive_timeout;
注意：@@wait_timeout 控制 JDBC/PyMySQL 等非交互连接；@@interactive_timeout 只影响 mysql -u 命令行这类交互会话。但部分连接池（如旧版 Druid）会主动声明 CLIENT_INTERACTIVE，所以两个都得查、都得调，否则改了也白改。
永久修改必须写进 my.cnf 并重启，SET GLOBAL 无效
SET GLOBAL wait_timeout = 600 是临时的，MySQL 重启就回滚。生产环境必须编辑配置文件：
- Linux 路径：
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf - Windows 路径：
my.ini - 在
[mysqld]段落下添加（两个参数建议设相同值，避免行为割裂）：
wait_timeout = 600<br>interactive_timeout = 600
⚠️ 切勿加到 [client] 段落——那只会改客户端行为，不影响服务端断连逻辑。改完必须 sudo systemctl restart mysql（不是 reload）。
HikariCP / Druid 连接池不配探活，改了 timeout 也白搭
MySQL 断掉连接后，连接池里还存着这个“僵尸连接”，下次取出就报 MySQL server has gone away 或 Communications link failure。必须让连接池主动验证：
- HikariCP 推荐配（
idle-timeout必须比wait_timeout小至少 30 秒，留出网络延迟余量）：
connection-test-query=SELECT 1<br>validation-timeout=3000<br>idle-timeout=300000<br>max-lifetime=1800000
- Druid 配：
testWhileIdle=true<br>timeBetweenEvictionRunsMillis=60000<br>minEvictableIdleTimeMillis=300000
关键点：idle-timeout（连接池侧）和 wait_timeout（MySQL 侧）要形成时间差，不能相等，更不能反过来。
真要“按用户限制”，只能靠应用层或代理层拦截
MySQL 不提供 GRANT ... UNTIL '09:00-18:00' 这类语法。可行路径只有两条：
- 在应用连接前做校验（如 Python 中
if datetime.now().hour not in range(9, 18): raise PermissionError(...)），注意时区统一 - 用 ProxySQL 或自研网关，在 TCP 层拦截连接请求，检查当前时间是否在允许窗口内，直接拒绝而非让 MySQL 处理
如果硬要在 MySQL 侧“模拟”，只能靠 cron 定时跑 ALTER USER 'staff'@'%' ACCOUNT LOCK/UNLOCK，但这只控制新连接，不影响已存在的活跃会话，且无法精确卡在闲置超时点断开——它跟 wait_timeout 是两套机制，别混用。
