定期审查MySQL权限需制度化自动化，覆盖全局、数据库、表/列级权限及账户状态，用SQL快速生成清单，通过脚本+定时任务固化审计，审查后须清理失效账户、收紧越权配置、记录变更依据。
定期更新账号权限不是“定时执行一条命令”就能完成的事，而是要建立可验证、可回溯、有触发条件的权限审查机制。
怎么发现权限已经过时或过度？
权限漂移往往发生在业务迭代后没人同步删权限。最直接的判断依据是：该账号最近 30 天没执行过任何被授予的权限类型操作。
- 查活跃度：
SELECT user, host, last_used FROM mysql.user WHERE last_used < DATE_SUB(NOW(), INTERVAL 30 DAY);（MySQL 8.0.23+ 支持last_used字段） - 查实际 SQL 行为：启用
general_log或代理层（如 ProxySQL、MaxScale）日志，反向提取该账号真实执行的语句类型 - 查高危残留：
SELECT User, Host, Drop_priv, Alter_priv, File_priv FROM mysql.user WHERE Drop_priv = 'Y' OR Alter_priv = 'Y' OR File_priv = 'Y';—— 即使当初没授，升级或误操作可能悄悄加上
如何安全地回收或收紧权限？
直接 REVOKE 有风险：应用可能因权限缺失突然报错。必须先确认影响范围。
- 先用
SHOW GRANTS FOR 'app_rw'@'10.20.30.%';导出当前权限快照，存档到配置管理系统 - 在测试环境模拟回收，比如
REVOKE DELETE ON mydb.orders FROM 'app_rw'@'10.20.30.%';，再跑一遍业务链路 - 生产环境执行前，加
/* audit: revoke DELETE on orders, ticket #DBSEC-2026-07 */注释，便于追溯 - 禁用
GRANT OPTION是底线：REVOKE GRANT OPTION ON *.* FROM 'app_rw'@'10.20.30.%';，防止权限扩散
哪些权限变更必须立即触发审查？
不是所有变更都等“定期”，有些必须实时响应。
- 新业务上线：对应账号创建后 24 小时内，必须完成最小权限核定（不能沿用旧模板）
- 人员离职或角色变更：
DROP USER或ALTER USER ... ACCOUNT LOCK;后，立刻检查其曾拥有的角色是否被其他用户继承 - MySQL 版本升级：8.0 升级后，
CREATE USER默认行为变化，mysql.user表结构新增字段，需重验权限逻辑 - 审计日志中出现
Access denied频次突增：说明权限已不足，但更可能是应用代码在尝试未授权操作，得先查原因再调权限
真正的难点不在命令怎么写，而在于把权限变更变成 DevOps 流水线里的一个可卡点环节——比如 CI/CD 发布前自动校验账号权限清单，或 DBA 审批工单强制关联 SHOW GRANTS 输出。否则，“定期”就只是日历上的一行提醒。
