MySQL如何审计用户授权和权限变更记录

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字段——它没有

1. mysql.user等系统表只存结果，不存操作日志
2. general_log性能开销大（QPS下降15–30%），且不区分成功/失败、不记录执行主机
3. 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';

1. QUERY_DML无效——它只捕获INSERT/UPDATE/DELETE，权限语句属于DDL
2. 日志默认写入/var/log/mysql/audit.log，需确保目录存在、属主为mysql、权限为600
3. 每条记录含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。

1. 先确认基础配置：SHOW VARIABLES LIKE 'log_bin';、SHOW VARIABLES LIKE 'binlog_format';、SHOW MASTER LOGS;
2. 用mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001解析，找### UPDATE mysql.user块
3. 注意时间戳在事件开头（如#240520 14:22:36），结合--start-datetime缩小范围
4. 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）不匹配而加载失败

1. SHOW PLUGINS;里查不到audit_log行，就说明它根本没加载
2. 设了audit_log_policy = ALL但日志文件始终为空？不是配置错了，是插件压根不存在
3. 别在plugin_dir下硬找audit_log.so——它99%不在那儿

真正要落地，得接受一个现实：MySQL原生不提供“开箱即用”的权限审计。要么用server_audit插件走标准路径，要么靠binlog做事后回溯——后者需要你提前知道哪些字段变了、什么时候变的，而且永远缺执行者上下文。