MySQL 默认不记录
GRANT、
REVOKE、
CREATE USER等权限变更操作，必须显式启用审计机制才能捕获——靠通用日志或二进制日志都不行，它们要么不记录权限语句（binlog 默认跳过），要么格式太粗（general_log 无结构、难过滤）。
用 server_audit 插件抓取权限变更事件
社区版 MySQL 最可靠的方式是加载
server_audit插件，并明确开启
QUERY_DDL和连接类事件。它能原生识别
GRANT、
REVOKE、
DROP USER等语句，并打上
QUERY或
CONNECT类型标签。 插件需提前放入
plugin_dir（如
/usr/lib/mysql/plugin/），再执行：
INSTALL PLUGIN server_audit SONAME 'server_audit.so';关键配置（写入
my.cnf并重启，或动态设置）：
SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL,QUERY_DML';<br>SET GLOBAL server_audit_logging = ON;<br>SET GLOBAL server_audit_file_path = '/var/log/mysql/audit.log';
QUERY_DDL是重点：它覆盖所有数据定义类操作，包括权限管理语句；而
QUERY_DML只捕获增删改查，不包含权限变更 日志中每条权限操作会带
user、
host、
query字段，例如：
"query":"GRANT SELECT ON mydb.* TO 'auditor'@'%'"
为什么不能依赖 general_log 或 binlog？
通用日志看似“啥都记”，但对权限审计实际无效：它记录的是客户端发来的原始字符串，不解析语义，
GRANT语句混在大量业务 SQL 中极难提取；而二进制日志默认不记录权限变更（除非显式开启
binlog_format=ROW并配合
log_bin_trust_function_creators=ON，但仍不保证稳定捕获）。
general_log开启后日志体积爆炸，且无用户上下文分离（比如无法区分是 root 执行还是应用账号执行）
binlog主要用于数据恢复和主从同步，
GRANT类语句在 STATEMENT 模式下可能被跳过，在 ROW 模式下根本不会出现 两者均不提供结构化字段（如操作类型、目标对象、执行结果成功/失败），无法做合规性回溯
企业版 audit_log 插件的差异点
MySQL Enterprise Edition 的
audit_log插件支持更细粒度策略，比如只审计特定用户或只记录失败的权限操作，但社区版做不到。如果你用的是企业版，配置更简洁：
[mysqld]<br>plugin-load = audit_log.so<br>audit_log_format = JSON<br>audit_log_policy = ALL<br>audit_log_file = /var/log/mysql/audit.log
audit_log_policy = ALL会记录所有连接和查询，包括权限语句；设为
LOGINS则只记登录，
QUERIES只记查询（不含 DDL） JSON 格式天然支持解析，可直接用
jq提取权限操作：
jq 'select(.query | contains("GRANT") or contains("REVOKE"))' /var/log/mysql/audit.log
注意：企业版插件名是 audit_log.so，不是
server_audit.so，加载失败通常因文件名或路径错误
触发器方案不适用于权限审计
有人想在
mysql.user或
mysql.db表上建触发器来监听权限变更，这在 MySQL 中不可行：系统表不允许创建用户触发器，执行会报错
ERROR 1356 (HY000): View 'mysql.user' references invalid table(s) or column(s)。 即使绕过限制（如用代理层拦截），也无法覆盖所有权限变更路径（例如通过
mysqldump --all-databases恢复时批量写入系统表） 权限变更本质是元数据操作，不是业务表 DML，必须由服务端审计插件在 SQL 解析阶段捕获 真正需要审计权限变更的场景（如等保三级、GDPR），必须用插件+日志轮转+权限隔离三者结合，缺一不可
最容易被忽略的一点：插件日志文件本身必须严格控制权限，
chown mysql:mysql /var/log/mysql/audit.log && chmod 600 /var/log/mysql/audit.log，否则审计日志可能被未授权用户篡改或删除——日志可信的前提，是日志自身不可抵赖。
