mysql不支持原生账号有效期，需用event+account lock模拟或应用层校验；password expire非权限控制，仅强制改密。
MySQL 本身不支持“带有效期”的账号授权
MySQL 没有原生的 GRANT ... UNTIL '2026-12-31' 这类语法。所谓“临时账号”或“时间限制权限”，必须靠外部机制模拟——要么用定时任务定期锁定/解锁用户，要么在应用连接时做时间校验。直接指望 MySQL 自动到期禁用账号，会踩坑。
用 EVENT + ACCOUNT LOCK 模拟到期控制（需开启 event_scheduler）
这是最接近“配置临时账号”的实操路径，但要注意它只影响新连接，已建立的连接不会被踢出。
- 先创建用户：
CREATE USER 'temp_dev'@'%' IDENTIFIED BY 'Temp@2026'; - 授予权限：
GRANT SELECT, INSERT ON app_db.* TO 'temp_dev'@'%'; - 创建自动锁定事件（比如 7 天后禁用）：
CREATE EVENT lock_temp_dev<br>ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 7 DAY<br>DO ALTER USER 'temp_dev'@'%' ACCOUNT LOCK;
- 确认事件启用：
SET GLOBAL event_scheduler = ON;（需 SUPER 权限） - ⚠️ 注意：系统时间不准、event_scheduler 被关闭、或 MySQL 重启未自动加载 event，都会导致失效
应用层校验才是可靠方案（推荐用于生产）
真正可控的“临时权限”，得由你的业务代码或中间件在每次建连前检查。MySQL 只管认证和授权，不管“这个用户现在是否该被允许”。
- 在用户表里加字段：
valid_until DATETIME和is_active TINYINT - 连接池初始化时执行：
SELECT 1 FROM user_access WHERE username = ? AND is_active = 1 AND valid_until > NOW(); - 校验失败则拒绝连接，或抛出明确错误（如
"Access expired on 2026-03-10"） - 优势：实时性强、可审计、支持灵活策略（比如按 IP+时间+角色组合判断）
- 劣势：多一层逻辑，但比起依赖 MySQL event 更稳
别误用密码过期（PASSWORD EXPIRE）当权限时效
MySQL 的 ALTER USER ... PASSWORD EXPIRE 控制的是「用户必须改密码才能登录」，不是「账号禁用」。即使密码过期，只要用户立刻重置密码，权限照旧——这和你想要的“到期即失权”完全不是一回事。
- 错误认知：
CREATE USER 'guest'@'%' IDENTIFIED BY 'x' PASSWORD EXPIRE INTERVAL 1 DAY;→ 用户仍能登录，只是被强制改密 - 正确理解：
PASSWORD EXPIRE是安全策略，不是访问控制开关 - 如果真要用，也得配合
ACCOUNT LOCK才算闭环，但依然无法替代应用层时间判断
MySQL 的权限模型是静态的，时间维度天然不在它的设计范围内。想靠一条 SQL 实现“到点自动停权”，本质上是在对抗它的架构逻辑——绕不开的妥协点，就是得自己补上那一层时间判断。
