应通过解析二进制日志（binlog）定位权限变更，需确保binlog_format为ROW或MIXED，使用mysqlbinlog配合grep筛选mysql.user等系统表的DML事件，并提取user_host、时间戳及操作类型。
MySQL 没开 general_log，怎么查谁改了权限？
默认情况下，MySQL 不记录 GRANT / REVOKE 操作的详细来源（IP、账号、时间戳），general_log 虽能捕获，但性能开销大、日志量爆炸，生产库基本不开。真正可用的是 mysql.general_log 表（需开启）或更靠谱的 performance_schema.audit_log_summary_by_account —— 但后者依赖企业版审计插件，社区版没这个表。
所以现实路径只有一条：查 mysql.user、mysql.db、mysql.tables_priv 等系统表的历史变更，前提是开启了二进制日志（binlog）且保留足够久。
-
binlog_format必须是ROW或MIXED，STATEMENT格式下 GRANT 语句不写入 binlog - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析 binlog，搜索UPDATE mysql.user或INSERT INTO mysql.db等操作 - 注意：
GRANT语句本身在ROW模式下不会直接出现，它会转成对权限表的 DML 操作，所以得盯住系统表的变更
如何从 binlog 提取权限变更记录并导出为可读文本？
核心是定位到权限表的写入事件，过滤掉无关 DML，再还原成接近原始 SQL 的形式。不能靠肉眼扫，得用工具链配合筛选。
- 先确认 binlog 文件名和位置：
SHOW MASTER LOGS;，挑最近有变更嫌疑的时间段对应文件 - 解析并过滤关键表：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A5 -B5 -E "(UPDATE.*mysql\.user|INSERT.*mysql\.db|DELETE.*mysql\.procs_priv)" - 加
--start-datetime="2024-05-20 14:00:00"和--stop-datetime缩小范围，避免全量解析 - 导出时建议重定向到临时文件：
mysqlbinlog ... > /tmp/priv_changes.log，后续用 awk/sed 提取 timestamp + user@host + table + change_type
audit_log 插件导出失败常见报错及绕过方法
如果你用的是 MySQL 5.7 企业版或 8.0+ 并启用了 audit_log 插件，但执行 SELECT * FROM audit_log 报错 Table 'mysql.audit_log' doesn't exist，说明插件没正确加载或日志输出模式不是 TABLE。
- 检查是否启用：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log';，状态必须是ACTIVE - 确认配置：
audit_log_policy必须含ALL或LOGINS，audit_log_format设为NEW（TABLE 模式才支持查询） - 如果插件已启但表不可见，可能是
audit_log_table变量未设为ON，需重启 mysqld 或动态设置：SET GLOBAL audit_log_table = ON; - 导出命令：
SELECT * FROM mysql.audit_log WHERE event_time > '2024-05-20' AND command_class IN ('grant','revoke','set_option') INTO OUTFILE '/var/lib/mysql-files/audit_priv.csv' FIELDS TERMINATED BY ',';
导出后分析权限变更的关键字段别漏看
不管是 binlog 解析结果还是 audit_log 表数据，真正能定位问题的字段就那几个，少一个都可能误判。
-
user_host（audit_log）或@@hostname+连接线程的USER()（binlog 中需结合 previous-gtid 或 event header 推断）—— 这才是实际执行人，不是CURRENT_USER() -
command_class值为grant或revoke才算权限变更，connect或query是干扰项 -
sql_text字段在 audit_log 中可能被截断，长度受audit_log_read_buffer_size限制；binlog 中则要看 ROW event 的table_map_event后紧跟的update_rows_event内容 - 时间字段必须用 UTC 还是本地时区？
event_time是 UTC，server_id和thread_id要交叉验证，防止多实例日志混在一起
权限变更往往发生在运维交接、临时提权或脚本误执行后几小时内，查日志时优先盯住 user_host 和时间窗口的交集，比全文扫描快得多。
