不能。mysql默认不记录权限变更，需主动启用audit_log插件或临时开启general_log并过滤关键词；但二者均有局限，flush privileges、直接改系统表及中间件代执行等操作仍难覆盖，须结合工单与流程管控。
MySQL 权限变更能被默认记录吗？
不能。MySQL 默认关闭所有审计功能，GRANT、REVOKE、DROP USER 等权限操作不会写入 Error log 或 general log，更不会自动归档到专门的审计日志中。想追踪谁在什么时候改了什么权限，必须主动启用审计机制。
用官方 audit_log 插件记录权限变更（MySQL 5.7+）
MySQL 企业版自带 audit_log 插件，社区版不包含；但部分发行版（如 Percona Server、mariadb）提供兼容实现。启用后可捕获 COM_QUERY 类型语句，包括权限相关 SQL。
- 确认插件可用：
SHOW PLUGINS;查看是否含audit_log状态为ACTIVE - 启用（需重启或动态加载）：
INSTALL PLUGIN audit_log SONAME 'audit_log.so'; - 关键配置（写入
my.cnf）：audit_log_format = json（推荐，结构清晰）audit_log_policy = ALL（或至少LOGINS,QUERIES）audit_log_file = /var/lib/mysql/audit.log - 权限变更语句（如
GRANT select ON db.* TO 'u'@'%'）会以 JSON 行形式落盘，含timestamp、user、query字段 - ⚠️ 注意：插件不解析 SQL 语义，只记录原始语句；若用存储过程封装权限操作，日志里只看到
CALL set_user_perms(...)，看不到实际授了哪些权限
用 general_log + 过滤关键词做轻量审计（通用方案）
适用于无法安装插件或仅需短期排查的场景。虽非专业审计，但能快速定位权限操作。
- 开启通用日志：
SET GLOBAL general_log = ON;，日志路径由general_log_file控制 - 权限语句特征明显，grep 可快速提取：
grep -iE "(grant|revoke|create user|drop user|alter user)" /var/lib/mysql/general.log - ⚠️ 风险点：
—general_log记录所有查询，IO 和磁盘增长极快，**绝不可长期开启**
— 日志无用户 IP、主机名等上下文，仅靠user@host字段识别，若多个账号共用同一用户名（如都叫admin），难以区分具体操作者
— 不记录执行结果（成功/失败），无法判断权限是否真正生效
权限变更审计最易忽略的盲区
即使开了 audit_log，仍有三类操作不会被常规策略覆盖：
-
FLUSH PRIVILEGES：该命令只是重载内存权限表，不触发 SQL 执行事件，audit_log 默认不记录 - 直接修改系统表：
UPDATE mysql.user SET authentication_string=... WHERE User='x'—— 属于 DML，会被记录，但语义模糊，需人工解读是否影响权限 - 通过 MySQL router、ProxySQL 或应用层连接池执行的权限语句：若中间件复用连接并代填用户信息，日志中
user字段可能显示中间件账号而非真实操作人
真正可靠的权限审计，得把插件日志 + 操作工单系统 + 数据库变更流程绑定，单靠日志本身只能补漏，不能兜底。