不能。MySQL Enterprise Audit 默认不记录权限变更的细粒度信息，仅标识GRANT/REVOKE语句类型与执行者；需设audit_log_policy=ALL才捕获，且日志中无结构化权限对象字段，须自行解析SQL或借助外部工具。
MySQL Enterprise Audit 能否直接记录谁改了哪些权限？
不能。MySQL Enterprise Audit 默认不捕获 GRANT、REVOKE 语句的权限目标细节（比如具体给了 SELECT 还是 DROP，作用在哪个表），只记录语句类型和执行者。它能告诉你“谁在什么时间执行了 GRANT”，但不会自动解析出“授予了 user_a 对 db1.t1 的 INSERT 权限”这种粒度。
必须开启 audit_log_policy=ALL 才能捕获权限变更语句
默认 audit_log_policy 是 LOGINS，只记连接/断开。要抓 GRANT/REVOKE，得设为 ALL 或至少 COMMANDS：
SET PERSIST audit_log_policy = 'ALL';
注意：SET PERSIST 写入 mysqld-auto.cnf，重启不丢失；若用 SET GLOBAL，重启后失效。另外，ALL 会显著增加日志体积和 I/O 压力，尤其高并发环境。
审计日志里怎么识别权限变更操作？
查 audit.log（路径由 audit_log_file 配置）时，重点过滤 command_class 字段值为 grant 或 revoke 的 JSON 条目：
-
user字段告诉你谁执行的 -
timestamp是精确到微秒的时间点 -
query字段包含原始 SQL（如GRANT SELECT ON db1.* TO 'u'@'%'），但需自己解析——MySQL 不提供结构化解析结果 - 没有
object_schema/object_name等字段对应权限对象，全靠正则或字符串提取
为什么 audit_log_format=NEW 仍然不够用？
即使启用了新版 JSON 格式（audit_log_format=NEW），它依然不扩展权限语义。比如 GRANT ALL PRIVILEGES ON *.* 和 GRANT CREATE USER 在日志里都只标 "command_class":"grant"，无法区分是普通权限还是管理权限。真正要做细粒度追踪，得额外做两件事：
- 在应用层或 DBA 操作流程中，强制要求权限变更走封装脚本（比如调用存储过程
log_grant_action()），把解析后的权限对象、类型、范围写进自定义审计表 - 用外部工具（如 Logstash + Grok）对
audit.log做二次解析，匹配GRANT后的关键词和ON后的对象模式
别指望开个参数就拿到“权限变更血缘图”——MySQL Enterprise Audit 提供的是原始动作快照，不是权限状态机。
