MySQL 8.0+ 的 WITH EXPIRE
权限是否真能自动过期？
不能。MySQL 原生不支持权限“自动过期”——
WITH EXPIRE是个常见误解，它实际只存在于
CREATE USER ... PASSWORD EXPIRE语句中，用于强制用户首次登录时改密，和权限（
GRANT）完全无关。所有通过
GRANT授予的权限，无论用什么方式创建用户，都不会随时间自动失效。
临时权限只能靠人工或脚本控制
所谓“临时权限”，本质是人为约定的短期授权行为，MySQL 不提供内置调度器来 revoke 过期权限。可行路径只有两条：
运维人员定期手动执行REVOKE+
FLUSH PRIVILEGES用外部脚本（如 Python / Shell）连接 MySQL，查询
mysql.role_edges或自建权限日志表，按预设时间戳批量回收
示例：假设你用一张
permission_grants表记录授权时间和有效期：
CREATE TABLE permission_grants ( id INT PRIMARY KEY AUTO_INCREMENT, user_host VARCHAR(255), privilege VARCHAR(64), db_table VARCHAR(255), granted_at DATETIME DEFAULT CURRENT_TIMESTAMP, expires_at DATETIME );
后续可通过定时任务查出已过期的记录，并生成对应的
REVOKE语句。
SET ROLE
和角色临时启用不是权限过期机制
SET ROLE仅控制当前会话中哪些角色处于激活状态，不影响权限本身的有效性。即使用户被授予了某个角色，只要没执行
SET ROLE role_name，该角色的权限就不会生效；但角色一旦被
SET ROLE激活，就持续到会话结束，不会因为时间推移而自动关闭。
常见误操作：
以为SET ROLE 'temp_role'@'%'后等 1 小时权限自动失效 → 实际不会 在应用连接池里调用
SET ROLE，但连接复用导致后续请求仍带着该角色权限 → 必须显式
SET ROLE NONE或断开连接
真正接近“自动过期”的折中方案：基于 proxy_user 或应用层网关
如果你需要强时效性（比如 API Token 绑定数据库权限），建议把权限控制前移到应用层：
用中间件（如 ProxySQL、MaxScale）根据 token 解析出用户身份和有效截止时间，动态映射到后端不同 MySQL 账号 应用自身维护 token 与权限关系，在每次 DB 请求前校验 token 是否过期，再决定是否用proxy_user方式切换上下文
MySQL 层面只保留一组最小权限账号，所有时效逻辑由上层承担。这比试图在 MySQL 内部模拟过期更可靠、更易审计。
最常被忽略的一点：
REVOKE操作本身不会立即影响已存在的活跃连接，那些连接仍保有旧权限，直到断开重连。这意味着“过期”在连接粒度上永远存在延迟窗口。
