能，MySQL通用日志（general_log）可记录GRANT/REVOKE等权限语句，但需动态开启、未被轮转清空，且日志为纯文本无操作者信息，仅记录语句本身。
MySQL 通用日志（general_log）真能抓到 GRANT/REVOKE 吗？
能，但前提是它开着，且没被覆盖或轮转丢弃。MySQL 的 general_log 是唯一默认就能记录 GRANT、REVOKE、CREATE USER、DROP USER 等权限语句的内置机制——不依赖插件，不依赖企业版，5.7 和 8.0 都支持。
-
general_log记录的是“所有到达服务器的 SQL 语句”，权限操作属于 DDL+管理语句，天然在范围内 - 但它不区分执行成功与否：哪怕
GRANT SELECT ON db.* TO 'x'@'y'因用户不存在而报错ERROR 1396 (HY000)，这条语句仍会进日志 - 日志是纯文本，无结构化字段（比如没有时间戳列、没有操作者账号），靠人工 grep 或脚本解析
- 开启后有性能开销，尤其高并发写场景；生产环境建议只临时启用，查完即关
怎么安全地启用并定位权限变更行？
别直接改 my.cnf 然后重启——万一配置写错，MySQL 启不来。优先用动态方式验证是否生效：
- 连上 MySQL 后执行：
SET GLOBAL general_log = 'ON';（需 SUPER 权限） - 确认输出目标：
SELECT @@log_output;返回FILE才会写磁盘；若为TABLE，则查mysql.general_log表（但该表默认关闭且不推荐用于审计） - 查日志路径：
SELECT @@general_log_file;，常见如/var/lib/mysql/general.log或/usr/local/mysql/data/mysqld.log - 权限变更语句特征明显：搜
GRANT、REVOKE、CREATE USER、DROP USER即可，例如：2026-02-28T14:22:03.123456Z 12345 Connect root@10.0.1.5 on using TCP/IP 2026-02-28T14:22:03.123789Z 12345 Query GRANT SELECT, INSERT ON app.* TO 'api_user'@'%'
为什么看了 general_log 还找不到最近的权限修改？
大概率不是没记，而是日志被清空、轮转或压根没开——这是最常踩的坑。
- Linux 下日志文件可能被 logrotate 每天切走，旧文件名带日期后缀（如
general.log-20260227），得翻历史归档 - 如果
general_log是动态开启的，服务重启后自动关闭（因为没写进配置），你查的是空文件 - MySQL 8.0+ 默认关闭
general_log，且log_output=TABLE时，mysql.general_log表默认是DISABLED，SELECT会返回空 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）禁用
general_log动态开关，只能通过控制台开启，且日志仅保留 7 天
有没有比 general_log 更靠谱的替代方案？
有，但代价不同：MySQL 企业版的 Audit Log 插件或 Percona Server 的 audit_log 是专为审计设计的，字段完整、支持过滤、可远程推送；开源环境下，general_log 仍是唯一零成本选择。
- 别指望 binlog：它只记录事务性数据变更（
INSERT/UPDATE/DELETE），GRANT属于 DDL，不写入 row-based binlog；statement-based 模式下虽可见，但不可靠（如含函数或变量时可能被重写） - 别查
mysql.user表的历史快照：它只存当前状态，没有变更时间戳，无法回溯“谁、何时、改了哪条权限” - 真正要长期审计，必须外接方案：用 filebeat 抓 general_log 实时推送 ES，或用 pt-query-digest 定期解析归档日志生成变更报告
general_log 不是银弹，但它是最接近“开箱即用”的权限操作记录方式——前提是知道它在哪、怎么活、以及它不会告诉你“谁执行的”，只告诉你“什么语句被执行了”。
