mysql 8.0社区版需手动加载audit_log插件并设audit_log_policy=all或logins，日志中通过"command_class":"grant"/"revoke"精准识别权限变更；performance_schema可临时查近期语句但需启用account_management仪器，general_log和binlog均无法满足结构化审计要求。
MySQL 8.0 本身不保存权限变更的“历史快照”，information_schema 和 performance_schema 都没有内置表能直接查出“谁在什么时候给谁授了什么权限”。真要审计 GRANT/REVOKE，必须依赖日志捕获——但不是随便开个日志就行，得选对机制、避开默认陷阱。
audit_log 插件是唯一原生支持 GRANT/REVOKE 审计的方案
MySQL 社区版 8.0.19+ 可手动加载 audit_log 插件，它会在日志中明确标记 "command_class":"grant" 或 "command_class":"revoke"。这不是通用查询日志，而是专为审计设计的结构化输出。
- 先确认插件存在：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log'；若为空，检查plugin_dir下是否有audit_log.so - 加载命令必须是：
INSTALL PLUGIN audit_log SONAME 'audit_log.so'（不是LOAD PLUGIN） -
audit_log_policy必须设为ALL或LOGINS；设成SYSTEM就不会记录GRANT -
audit_log_file要用绝对路径，且确保 MySQL 进程用户（如mysql）对该路径有写权限，比如/var/log/mysql/audit.log - 日志格式建议用
JSON，配合jq实时过滤：tail -f /var/log/mysql/audit.log | jq 'select(.command_class == "grant" or .command_class == "revoke")'
performance_schema 可临时抓取最近的授权语句（无需插件）
如果你没权限装插件，又需要快速排查最近几小时的异常 GRANT，performance_schema.events_statements_history_long 是唯一不用重启、不依赖外部组件的选项。但它只保留内存中的近期事件，且默认不采集账户管理类语句。
- 先确认
performance_schema已启用：SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'返回ON - 启用采集：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'statement/abstract/account_management' - 打开消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_statements_current') - 查最近授权：
SELECT USER, HOST, SQL_TEXT, TIMER_START FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE 'GRANT%' AND TIMER_START > UNIX_TIMESTAMP(NOW() - INTERVAL 1 HOUR) * 1000000000 - 注意：
TIMER_START是纳秒级，不能直接和NOW()比较；HOST字段可能显示'%'或模糊网段，这是高危信号
别碰 general_log：它看起来最简单，实际最不可靠
general_log 虽然能记下 GRANT 语句，但既无身份上下文（分不清连接用户和执行者），也不记录执行结果（失败的 GRANT 也记，但不带错误码），更无法关联应用来源或 IP。生产环境一开就可能填满磁盘。
-
general_log默认关闭，MySQL 8.0+ 启动后完全不写；SET GLOBAL general_log = ON只对当前会话生效，服务重启即失效 - 若设
log_output = 'TABLE'，日志写入mysql.general_log表，但该表默认是 CSV 引擎、无索引、MySQL 8.0+ 默认禁用——SELECT返回空也不报错 - 云数据库（如阿里云 RDS）通常屏蔽
SET GLOBAL general_log，只能通过控制台开启，且日志仅保留 7 天 - Linux 下
logrotate每天轮转，真实文件可能是general.log-20261014，不是general.log - 提取语句用
grep -iE "(grant|revoke|create user|drop user|alter user)"看似可行，但日志里user@host是连接用户，不是真正执行者
binlog 只能间接还原权限变更（慎用）
binlog 不记录 GRANT 原文，只记录对 mysql.user、mysql.db 等系统表的 DML 更新。你看到的是 UPDATE mysql.user SET ...，而不是原始的 GRANT SELECT ON db.* TO 'u'@'%'。可读性差，还容易误判。
- 前提：必须设
binlog_format = ROW（STATEMENT在 8.0.30+ 已弃用），且开启binlog_rows_query_log_events = ON，否则mysqlbinlog --verbose也看不到原始 SQL - 解析命令：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A2 -B2 -i "update mysql\.user\|insert into mysql\.db" - 风险：DDL/DML 混在一起，无法区分是人操作还是备份工具触发；失败的权限变更（如用户不存在）根本不会写入 binlog
- 它适合事后追溯“哪些系统表被改了”，但不适合回答“谁执行了哪条 GRANT”
真正能落地的权限审计，只有两条路：长期用 audit_log 插件（需提前部署、配置合理轮转），或短期用 performance_schema 抓现场。其他方式要么缺关键字段，要么性能扛不住，要么在云环境下根本不可用。最常被忽略的是：插件加载后不设 audit_log_policy，或日志路径权限不对——这两点导致 90% 的“开了审计却没日志”问题。
