MySQL不支持原生临时账号权限，唯一可行方案是CREATE USER PASSWORD EXPIRE AFTER N（8.0.11+），它强制N天后首次操作报错ERROR 1820要求重置密码，需配合SET PERSIST default_password_lifetime = 0防全局覆盖，且不适用于5.7等低版本。
MySQL 没有“临时权限账号”这个东西——只有临时密码策略，且仅靠它无法真正控制权限生命周期。 所谓“创建带有效期的账号”，本质是利用 PASSWORD EXPIRE AFTER N 触发登录后首次操作拦截，而账号本身、权限、连接都照常存在。想靠一条 GRANT 命令就实现“7天后自动失权”，会漏掉关键环节，导致权限持续生效甚至被滥用。
CREATE USER PASSWORD EXPIRE AFTER N 是唯一能落地的“有效期”语法
这是 MySQL 8.0.11+ 唯一支持的相对有效期写法，必须在建号时声明，且只对新密码生效：
-
CREATE USER 'tool_2026'@'10.20.%' IDENTIFIED BY 'p@ss2026' PASSWORD EXPIRE AFTER 3;—— 创建即生效，3 天后用户首次执行任何语句（哪怕SELECT 1）都会报错ERROR 1820 - 如果只写
ALTER USER 'tool_2026'@'10.20.%' PASSWORD EXPIRE AFTER 3;（不带IDENTIFIED BY），MySQL 会静默忽略，不报错也不生效 - 低版本（如 5.7）完全不识别该语法，执行会直接报
ERROR 1064，别试 - 必须搭配
SET PERSIST default_password_lifetime = 0;，否则全局设置（如默认 90 天）可能覆盖用户级策略
GRANT 必须在 CREATE USER 之后显式执行，且不能用 USAGE 替代
权限不是“附着在账号上”的，而是独立存储的记录。常见错误是跳过 CREATE USER 直接 GRANT，或误以为 GRANT USAGE 能开个“空壳账号”：
-
GRANT SELECT ON `app_db`.* TO 'tool_2026'@'10.20.%';会失败：用户不存在，报ERROR 1396 (HY000): Operation GRANT failed for 'tool_2026'@'10.20.%' -
GRANT USAGE ON *.* TO 'tool_2026'@'10.20.%';看似成功，但后续所有操作都会被拒，报ERROR 1044 (42000): Access denied for user - 正确顺序：先
CREATE USER+PASSWORD EXPIRE AFTER N，再GRANT SELECT, SHOW VIEW ON `app_db`.*，最后FLUSH PRIVILEGES; - 务必
REVOKE SHOW DATABASES ON *.* FROM 'tool_2026'@'10.20.%';，否则第三方工具能列出所有库名，暴露架构
EVENT 自动锁定只能补位，不能替代应用层判断
用 ALTER USER ... ACCOUNT LOCK 配合事件调度器，确实能在指定时间点让账号无法新建连接，但它对已存在的连接完全无效：
CREATE EVENT lock_tool_2026 ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 3 DAY DO ALTER USER 'tool_2026'@'10.20.%' ACCOUNT LOCK;- 事件生效后，新连接会被拒绝，但长连接池（比如 DataGrip、Navicat 或 Python 的
pymysql连接池）仍可继续查询、导出数据 - 事件依赖
event_scheduler = ON，MySQL 重启后若未持久化配置，事件不会自动加载 - 主从架构中，事件只在当前节点创建，从库不会同步，状态不一致风险高
真正可控的“临时访问权”，得由你的业务代码或中间件在每次建连前检查时间戳；MySQL 只管认证和授权，不管“这个用户现在是否该被允许”。PASSWORD EXPIRE AFTER N 是起点，不是终点——它拦得住第一次操作，拦不住已建立的连接，更拦不住绕过 MySQL 的直连行为。
