mysql不支持grant语句设置过期时间，因其权限系统为静态快照式设计，授权永久生效直至显式revoke；所谓“临时权限”需依赖密码过期、外部脚本清理及应用层校验组合实现。
MySQL 不支持 GRANT 语句设置过期时间，所谓“带有效期的权限”必须靠外部机制补足——直接写 GRANT ... EXPIRE 或类似语法会报错或完全无效。
为什么 GRANT 没有 EXPIRE 参数
MySQL 的权限系统是静态快照式设计：一旦执行 GRANT SELECT ON db.* TO 'user'@'%'，这条授权就永久生效，直到你显式 REVOKE。官方从未实现过 GRANT ... UNTIL '2026-12-31' 或 WITH EXPIRE 这类语法。网上搜到的“GRANT ... WITH EXPIRE”基本是混淆了 PASSWORD EXPIRE 和权限本身——后者只管密码，不碰权限。
真正能用的临时权限落地方式
生产环境推荐组合使用以下三项，缺一不可：
- 用
CREATE USER ... PASSWORD EXPIRE AFTER N设置密码有效期（MySQL 8.0.19+），让账号在 N 天后首次登录即被拦截； - 严格限定
GRANT范围：只给具体库表，禁用SHOW DATABASES，避免INFORMATION_SCHEMA泄露结构； - 配合外部脚本定期清理：查
mysql.user表中password_last_changed超期的用户，自动执行DROP USER或REVOKE+FLUSH PRIVILEGES。
容易踩的坑
这些细节不处理，临时权限就形同虚设：
-
PASSWORD EXPIRE AFTER 7只在用户首次登录时触发检查，已建立的连接不受影响——如果外包开着长连接，权限实际还在； - 没关
event_scheduler就依赖 EVENT 自动锁账号？那事件根本不会运行； - 误以为
SET GLOBAL wait_timeout = 600能“让权限过期”，其实它只是断开空闲连接，不影响权限有效性； - 用
GRANT SELECT ON *.*给临时用户，等于把所有库名、表结构都暴露出去，哪怕只读也很危险。
最稳的路径不是堆砌 MySQL 内置功能，而是把时效判断前移到应用层或网关。MySQL 层只保留最小权限账号，所有“是否该放行”逻辑由上层决定——这才是 2026 年真实生产环境里没人明说但都在用的底线方案。
