MySQL 没有“权限超时”或“权限过期”机制
直接说结论：MySQL 本身不支持给用户权限设置有效期（比如“该 SELECT 权限仅生效30天”）。它没有类似 GRANT ... EXPIRE AFTER 或权限自动失效的内置功能。所谓“权限超时”，是常见误解，实际想控制的是连接空闲、查询执行、锁等待等**行为超时**，而非权限本身的生命周期。
你真正需要的：三类关键超时参数及其用途
用户常把“登录后断开”“查太久被杀”“锁太久报错”误认为“权限过期”。其实对应的是三个独立系统变量，作用场景完全不同：
-
wait_timeout和interactive_timeout：控制**连接空闲多久后自动断开**（单位：秒）。前者针对程序连接（如 JDBC），后者针对命令行客户端。设为600就是 10 分钟无操作即断连 —— 这不是权限没了，而是连接被服务器主动关了。 -
max_execution_time：限制单条SELECT语句最长执行时间（单位：毫秒）。超时抛出错误ERROR 3024 (HY000)，但事务状态可能已不一致，需应用层兜底处理回滚。 -
innodb_lock_wait_timeout：InnoDB 行锁等待超时（单位：秒）。默认 50 秒，超时后当前语句失败，事务仍活跃 —— 不影响权限，只中断锁等待。
想实现“类权限过期”？只能靠外部管控
如果业务真有“临时授权”需求（例如外包人员只准访问 7 天），MySQL 无法原生支持，必须组合外部手段：
- 用定时任务（如 Linux
cron或 Windows Task Scheduler）定期执行DROP USER或REVOKE+FLUSH PRIVILEGES； - 在应用层加权限校验中间件，结合数据库外的用户中心（如 OAuth2 token 有效期）动态控制 SQL 执行权限；
- 创建专用账号，配合资源限制（
MAX_QUERIES_PER_HOUR等），虽不能精确到秒级过期，但可大幅降低滥用风险。
注意：WITH MAX_CONNECTIONS_PER_HOUR 5 这类限制写在 CREATE USER 里，是永久生效的，不会随时间自动恢复，也非“过期”，只是配额控流。
配置时最容易踩的坑
很多人改完就以为万事大吉，结果线上出问题才意识到细节没对上：
-
SET GLOBAL只影响新连接，已有连接仍用旧值 —— 想立刻生效得让应用重连，或干脆改配置文件my.cnf并重启 MySQL； -
max_execution_time在 MySQL 5.6 是max_statement_time（毫秒），且不支持语句级 hint；5.7+ 才统一为max_execution_time并支持/*+ MAX_EXECUTION_TIME(2000) */； - MySQL Workbench、Navicat 等客户端自身也有网络超时（如默认 30 秒），即使数据库设了 300 秒，客户端先断了你也收不到结果；
- 应用用了连接池（如 HikariCP），必须同步调小
maxLifetime（建议比wait_timeout小 60 秒），否则池子里的“僵尸连接”会被 MySQL 主动踢掉，引发Connection reset。
权限本身不会过期，但连接、查询、锁的“耐心”会 —— 把这三个超时参数和应用层行为对齐，才是真实可控的方案。
