能，MySQL通用查询日志可捕获GRANT操作，但默认关闭，需手动启用SET GLOBAL general_log = ON，并确保用户有SUPER或SYSTEM_VARIABLES_ADMIN权限。
MySQL通用查询日志能捕获GRANT操作吗
能，但默认关闭，且必须手动启用。通用查询日志（general_log）会记录所有到达MySQL服务器的SQL语句，包括GRANT、REVOKE、CREATE USER等权限相关操作——前提是日志已开启且格式支持可读性。
常见错误现象：SELECT @@general_log 返回 OFF，或日志文件为空；误以为开启了slow_query_log就能看到授权行为；用binlog去查GRANT，结果发现它不记（因为GRANT是DDL，但MySQL 5.7+默认不写入binlog，除非binlog_format=ROW且启用了log_bin_trust_function_creators等额外配置）。
- 启用前先确认用户有
SUPER或SYSTEM_VARIABLES_ADMIN权限（MySQL 8.0+） - 运行
SET GLOBAL general_log = ON，再用SELECT @@general_log_file查日志路径 - 日志格式优先选
FILE（general_log_file指定路径），别用TABLE（mysql.general_log表），因为写入频繁时可能拖慢权限操作本身 - 注意磁盘空间和敏感信息泄露风险：日志里明文记密码（如
CREATE USER 'a'@'%' IDENTIFIED BY '123'），生产环境开启需严格限制访问权限
如何快速从通用日志中提取GRANT/REVOKE事件
通用日志是纯文本，每行一条语句，时间戳+线程ID+命令。直接grep最有效，但要注意大小写、空格和换行干扰（MySQL日志不会把长GRANT拆成多行，这点比慢日志友好）。
- 用
grep -i "grant\|revoke\|create user\|drop user" /var/lib/mysql/general.log快速筛选 - 加
-B1 -A1显示上下文，避免漏掉带注释或变量的授权语句（比如/* app:admin */ GRANT ...） - 如果日志量大，先用
awk '$1 ~ /^[0-9]{6} [0-9]{2}:[0-9]{2}:[0-9]{2}$/ {if(/GRANT|REVOKE/) print}'过滤带时间戳的行，减少误匹配 - MySQL 8.0+ 用户注意：
CREATE ROLE、SET DEFAULT ROLE也属于权限操作，需一并纳入关键词
为什么不用audit log插件而选通用日志
MySQL企业版的audit_log插件确实更专业：支持JSON格式、细粒度过滤、独立权限控制。但社区版没有，且即使企业版，部署后若未配置audit_log_policy=ALL或audit_log_include_accounts，也可能漏掉非预期账户的操作。
- 通用日志是唯一社区版开箱即用、无需编译安装的方案
-
audit_log对性能影响更明显（尤其高并发权限变更场景），而general_log在低频授权操作下几乎无感 - 通用日志路径可控、轮转简单（配合
logrotate即可），audit_log的JSON日志需要额外解析工具才能做聚合分析 - 但别指望它替代审计合规要求：它不记录执行结果（比如
GRANT是否成功）、不记录客户端IP（除非日志里有Connect行且你做了关联），仅作操作追溯用
权限监控上线后最容易被忽略的三件事
日志开了、脚本写了、告警配了，但过两周发现漏报，大概率栽在这三点上。
-
general_log是会话级变量，SET GLOBAL生效后，新连接才写日志；已有连接不受影响，重启mysqld或杀掉旧连接才能全覆盖 - 日志文件权限不对：
chown mysql:mysql /var/lib/mysql/general.log必须做，否则MySQL进程无法追加写入，现象是文件大小不再增长 - 没关日志轮转自动清理：某些云数据库管理后台（如阿里云RDS）或自建
logrotate配置可能定期清空general_log_file，导致历史授权记录丢失，得同步备份或改用syslog转发
真正难的不是打开日志，而是让日志持续、完整、可定位地活着——尤其当DBA自己也是被监控对象时，日志文件的归属、访问链路、保留周期，都得提前想清楚。
