MySQL社区版默认不记录任何GRANT/REVOKE操作，必须启用server_audit插件并配置QUERY_DDL事件才能可靠审计，日志包含user、host、timestamp及完整SQL语句。
MySQL社区版默认不记录任何GRANT/REVOKE操作
直接说结论：你查information_schema、performance_schema，甚至翻error.log或general_log，都找不到谁在什么时候执行了GRANT SELECT ON db.t TO 'u'@'%'。这不是配置漏了，是MySQL社区版根本没设计这个功能。
常见错误现象包括：
– SHOW GRANTS FOR 'u'@'%'只显示当前快照，看不出变更时间
– 开了general_log后发现日志里混着大量SELECT/INSERT，GRANT语句被淹没且无用户上下文
– 以为mysql.user表有updated_at字段——它没有
-
mysql.user等系统表只存结果，不存操作日志 -
general_log性能开销大（QPS下降15–30%），且不区分成功/失败、不记录执行主机 -
binlog本身不保证记录权限语句——取决于binlog_format和执行方式
社区版唯一靠谱方案：启用server_audit插件抓QUERY_DDL
这是目前MySQL社区版最轻量、最稳定、日志最清晰的权限审计路径。它不依赖企业版，也不需要编译，只要插件文件存在就能用。
实操分三步：
– 先确认插件路径：SHOW VARIABLES LIKE 'plugin_dir';，然后检查目录下是否有server_audit.so（常见路径：/usr/lib64/mysql/plugin/server_audit.so）
– 安装并启用：INSTALL PLUGIN server_audit SONAME 'server_audit.so';
– 关键配置（必须设QUERY_DDL）：SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL';、SET GLOBAL server_audit_logging = ON;、SET GLOBAL server_audit_file_path = '/var/log/mysql/audit.log';
-
QUERY_DML无效——它只捕获INSERT/UPDATE/DELETE，权限语句属于DDL - 日志默认写入
/var/log/mysql/audit.log，需确保目录存在、属主为mysql、权限为600 - 每条记录含
user、host、timestamp和完整query字段，例如："query":"GRANT INSERT ON test.* TO 'dev'@'10.0.1.%'"
ROW格式binlog下如何从mysql.user变更反推权限操作
如果你无法安装插件，又恰好开了binlog_format = ROW且log_bin = ON，这条路能救急，但得手动拼信息。
权限变更最终会落到mysql.user、mysql.db等系统表的DML上。比如GRANT SUPER ON *.* TO 'a'@'%'会触发对mysql.user表的UPDATE事件，把Super_priv字段从N改成Y。
- 先确认基础配置：
SHOW VARIABLES LIKE 'log_bin';、SHOW VARIABLES LIKE 'binlog_format';、SHOW MASTER LOGS; - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001解析，找### UPDATE mysql.user块 - 注意时间戳在事件开头（如
#240520 14:22:36），结合--start-datetime缩小范围 -
UPDATE事件里看不到原始GRANT语句，只能靠字段变化反推：比如authentication_string更新说明改了密码，Grant_priv='Y'说明开了授权权
别碰audit_log插件——社区版基本不可用
看到文档里写audit_log_policy = ALL就以为能用？醒醒，MySQL社区版默认不带audit_log.so。强行INSTALL PLUGIN audit_log SONAME 'audit_log.so'只会报错：Plugin 'audit_log' is not loaded。
真实情况是：
– 企业版自带，社区版不包含
– Percona Server或MariaDB可能提供兼容版本，但路径、文件名、ABI全都不统一
– 即使找到第三方audit_log.so，也极大概率因MySQL小版本号（如8.0.34 vs 8.0.33）不匹配而加载失败
-
SHOW PLUGINS;里查不到audit_log行，就说明它根本没加载 - 设了
audit_log_policy = ALL但日志文件始终为空？不是配置错了，是插件压根不存在 - 别在
plugin_dir下硬找audit_log.so——它99%不在那儿
真正要落地，得接受一个现实：MySQL原生不提供“开箱即用”的权限审计。要么用server_audit插件走标准路径，要么靠binlog做事后回溯——后者需要你提前知道哪些字段变了、什么时候变的，而且永远缺执行者上下文。
