GRANT权限不会自动过期，不手动REVOKE将长期存在，导致误操作扩散、审计痕迹覆盖、高危账号变后门；必须通过脚本绑定GRANT/REVOKE、审批平台管控、工单锁死流程来保障回收。
MySQL 临时提权后权限没及时回收，会出什么问题
直接说结论：GRANT 加的权限不会自动过期，不手动 REVOKE 就一直存在，哪怕用户只用一次、连接已断开。常见后果包括：运维误操作扩散、审计日志里权限变更痕迹被覆盖、高危账号（比如 'dba_temp'@'%'）长期滞留变成后门入口。
怎么安全地做“窗口期提权 + 自动回收”
MySQL 本身不支持带 TTL 的权限，所谓“自动”必须靠外部机制兜底。关键不是加权限，而是让回收动作不可跳过、不可遗忘：
- 所有
GRANT操作必须和一条对应的REVOKE命令写在同一脚本里，用注释明确标注窗口截止时间，例如：GRANT PROCESS ON *.* TO 'monitor_user'@'10.20.30.%'; -- 提权开始：2024-06-15 14:00\nREVOKE PROCESS ON *.* FROM 'monitor_user'@'10.20.30.%'; -- 必须在 14:30 前执行
- 禁止在交互式
mysql客户端里手敲GRANT；统一走带审批的运维平台或 Ansible playbook，确保REVOKE步骤被纳入流程校验 - 如果真要“自动”，可用
mysql_event+ 存储过程模拟，但要注意：MySQL 8.0+ 才支持事件调度器默认开启，且事件无法跨实例触发，实际生产中极少用——不如定时任务调mysql -e "REVOKE ..."可靠
哪些权限特别容易漏回收、风险最高
不是所有权限都一样危险。以下几类一旦赋予，又没及时清理，极易引发越权或数据泄露：
-
SUPER：能绕过大部分权限检查，修改全局变量、杀任意线程，回收前务必确认无残留连接 -
PROCESS：可看到其他用户正在执行的 SQL，含敏感参数（如WHERE password = 'xxx'），常被监控工具临时申请，但回收不及时就会暴露业务逻辑 -
FILE：配合SELECT ... INTO OUTFILE或LOAD DATA INFILE可读写服务器文件系统，权限生命周期必须和具体任务强绑定 - 对
mysql.user表的SELECT权限：等于把所有账号密码哈希（authentication_string字段）暴露给该用户，几乎等同于 root 权限泄露
如何快速发现漏回收的临时权限
别等出事再查。日常巡检就该跑这条语句，它能揪出明显异常的宽泛授权：
SELECT user, host, privilege_type, is_grantable \nFROM information_schema.role_table_grants \nWHERE grantee LIKE '%temp%' OR host LIKE '%.%' OR user LIKE '%tmp%';
更实用的是对比权限快照：每次维护窗口前用 mysqldump -t mysql.user mysql.db 备份权限表，窗口结束后用 diff 对比，任何新增行都得人工确认是否已回收。
最麻烦的点其实是人——权限加得太快，回收时没人记得当时为什么加、加给谁、该删哪几行。所以真正的防线不在 SQL，而在每次 GRANT 后必须填一条工单，状态锁死为「待回收」，直到 REVOKE 执行并验证成功才允许关闭。
