MySQL默认不记录权限变更，唯一可靠路径是解析binlog；需binlog_format为ROW或STATEMENT，用mysqlbinlog配合grep筛选GRANT/REVOKE或系统表DML事件，并结合时间戳与字段值变化反推操作。
MySQL没有内置权限变更审计日志
MySQL默认不记录GRANT、REVOKE、CREATE USER等权限操作的历史，information_schema和performance_schema里查不到谁在什么时候改了什么权限。想追溯这类变更，唯一可靠路径是解析二进制日志（binlog），前提是：binlog_format = ROW或STATEMENT且开启了log_bin。
确认binlog是否启用且包含权限语句
权限类语句在binlog中是否可查，取决于格式和执行方式：
-
binlog_format = STATEMENT：GRANT/REVOKE会被完整记录为文本，最易识别 -
binlog_format = ROW：权限表（如mysql.user、mysql.db）的DML变更会以行事件形式出现，但需手动关联到具体权限操作 -
binlog_format = MIXED：通常降级为STATEMENT记录权限语句，行为较稳定 - 如果用
mysql_native_password插件或8.0+的caching_sha2_password，密码哈希变更也会写入mysql.user表，可在ROW模式下通过UPDATE mysql.user事件定位
先运行SHOW VARIABLES LIKE 'log_bin';和SHOW VARIABLES LIKE 'binlog_format';确认基础配置；再用SHOW MASTER LOGS;看当前有哪些binlog文件。
用mysqlbinlog提取含GRANT/REVOKE的语句
直接过滤文本最高效，适用于STATEMENT或MIXED模式：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A 2 -B 2 "GRANT\|REVOKE\|CREATE USER\|DROP USER"
关键点：
-
--base64-output=DECODE-ROWS避免跳过ROW事件干扰输出 -
-v（或--verbose）让mysqlbinlog把ROW事件转成伪SQL，便于阅读 - 时间戳在每条事件开头，形如
#240520 14:22:36，结合mysqlbinlog --start-datetime可缩小范围 - 注意区分注释行（以
#开头）和真实SQL——权限语句一定出现在###分隔符之后的实际执行部分
ROW模式下从mysql.user表变更反推权限操作
当只有ROW格式且没开general_log时，得从底层表变更入手：
- 权限修改本质是更新
mysql.user、mysql.db、mysql.tables_priv等系统表 - 用
mysqlbinlog -v mysql-bin.000001 | grep -A 10 "UPDATE.*mysql\.user"定位更新事件 - 重点看
@1=（User字段）、@2=（Host字段）以及权限列如@15=（Select_priv）、@16=（Insert_priv）的值变化 - 密码字段如
@3=（authentication_string）被更新，往往对应ALTER USER ... IDENTIFIED BY，而非GRANT
这种分析需要熟悉mysql.user表结构，不同MySQL版本字段顺序可能不同，8.0比5.7多出password_last_changed等列，别硬记序号，用DESC mysql.user;核对。
真正难的不是解析命令，而是binlog保留时间短、权限操作常跨多个事务、系统表更新和显式GRANT语句可能不一一对应——比如一个GRANT ALL ON *.*会触发mysql.user和mysql.global_grants两处写入，漏掉任一就还原不全。
