MySQL 8.0无原生“临时用户”，必须协同密码过期、主机限制与外部清理实现；仅用GRANT/REVOKE无法中断已有连接，EVENT执行REVOKE需SUPER权限且不安全，PASSWORD EXPIRE仅阻断新操作起点。
MySQL 8.0 中没有“临时用户”这个原生类型，所谓“临时”，必须靠密码过期 + 主机限制 + 外部清理三者协同实现；单靠 GRANT 或 EVENT 都会漏掉活跃连接或权限残留。
为什么不能只用 GRANT + REVOKE 控制临时访问
你执行 REVOKE SELECT ON db.tbl FROM 'tmp_user'@'%'; 后，用户仍可能继续读取数据——因为已有连接不会自动失效。应用层若用了连接池（如 Python 的 pymysql 或 Java 的 HikariCP），旧连接会复用数分钟甚至数小时，权限变更完全不生效。
-
GRANT和REVOKE只影响新会话的权限检查，不中断当前连接 -
FLUSH PRIVILEGES在 MySQL 8.0+ 多数场景下非必需，但某些容器化部署或配置异常时仍需显式调用 - 反复
GRANT/REVOKE容易留痕、审计难，且一旦脚本失败或网络中断，权限就卡在中间态 - EVENT 调度器默认无法执行
REVOKE，报错ERROR 1227 (42000)，除非开启event_scheduler=ON并授予SUPER权限，但这本身又扩大了攻击面
用 PASSWORD EXPIRE 实现账号级“自动失效”
这是 MySQL 原生最可靠的时间控制机制，但仅作用于登录认证环节：密码过期后，用户能连上，但首次执行任何语句就会被拦住，报 ERROR 1820。
- 创建时设有效期：
CREATE USER 'tmp_api'@'10.10.20.%' IDENTIFIED BY 'a1b2c3' PASSWORD EXPIRE AFTER 2;（2 天后首次操作失败） - 或后续修改：
ALTER USER 'tmp_api'@'10.10.20.%' PASSWORD EXPIRE AT '2026-10-05 10:00:00'; - 必须确保全局变量未覆盖：
SET PERSIST default_password_lifetime = 0;，否则PASSWORD EXPIRE可能被忽略 - 注意：过期不影响已建立的长连接，所以它不是“实时断连”，而是“阻止新操作起点”
必须配合主机限制和最小权限
光有时间控制不够，'tmp_user'@'%' 这种写法等于把门钥匙扔在街上。真正可控的临时用户，必须从源头缩小攻击面。
- 显式指定 IP 段：
CREATE USER 'tmp_audit'@'192.168.5.0/255.255.255.0' IDENTIFIED BY 'audit2026';（MySQL 8.0.29+ 支持 CIDR） - 只授必要权限：
GRANT SELECT, SHOW VIEW ON `report_db`.* TO 'tmp_audit'@'192.168.5.0/255.255.255.0';，禁用GRANT OPTION - 禁用元数据库暴露：
REVOKE SHOW DATABASES ON *.* FROM 'tmp_audit'@'192.168.5.0/255.255.255.0';，否则第三方工具能扫出所有库名 - 如需查锁或慢日志，单独授权：
GRANT SELECT ON performance_schema.* TO 'tmp_audit'@'192.168.5.0/255.255.255.0';，但要清楚这会暴露 SQL 文本和参数
定期清理不能靠人盯，得用脚本+通知
靠文档备注“三天后删”或钉钉提醒，90% 会失效。必须把清理动作固化进运维流程。
- 查出疑似临时账户：
SELECT User, Host, password_expired, account_locked FROM mysql.user WHERE User REGEXP '^tmp_|^dev_|^tool_'; - 结合创建时间判断（需外部记录，MySQL 不存创建时间）：推荐在用户名里嵌入日期，如
'tmp_20261001_dev'@'%' - 清理脚本示例（shell）：
mysql -u root -e "DROP USER 'tmp_20261001_dev'@'%'; FLUSH PRIVILEGES;" - 加一层安全确认：脚本先输出将删用户列表，要求人工输入
YES才执行，避免误删
真正容易被忽略的是连接池行为和主机匹配细节：一个 'user'@'localhost' 用户，从 Docker 容器内用 127.0.0.1 连，会被当成 'user'@'127.0.0.1'，权限不生效；而 % 不匹配 localhost，这是 MySQL 认证逻辑的硬规则，不是 bug。
