如何在MySQL中开启并配置通用查询日志用于审计？-mysql教程-PHP中文网

通用查询日志（general_log）能记录所有客户端连接与原始sql语句，是最轻量级审计手段，但无法替代audit_log等专业审计插件；开启后无日志通常因log_output=none、general_log_file路径不可写或selinux/apparmor拦截。

如何在mysql中开启并配置通用查询日志用于审计？

通用查询日志（general_log）能记录所有客户端连接与原始SQL语句，是快速审计操作的最轻量级手段——但它不是真正的审计插件，不能替代 server_audit 或企业版 audit_log，开错就可能丢日志、写满磁盘或查不到关键语句。

SET GLOBAL general_log = ON 为什么没看到日志？

执行后日志没生成，大概率是三个环节断了：

log_output 是 NONE：这是静默失效的元凶。必须显式设为 'FILE' 或 'TABLE'，否则 MySQL 直接丢弃日志
general_log_file 路径不可写：MySQL 进程用户（通常是 mysql）对父目录无写权限，或路径中某级目录不存在（general_log_file 不会自动创建多级目录）
SELinux/AppArmor 拦截：Ubuntu/CentOS 上常见，用 sudo aa-disable /usr/sbin/mysqld 或 setenforce 0 临时验证

确认状态的最小命令组合：

SET GLOBAL general_log = ON;
SET GLOBAL log_output = 'FILE';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';
SHOW VARIABLES LIKE 'general_log%';

执行完立刻 ls -l /var/log/mysql/ 看文件是否生成、属主是否为 mysql。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

FILE 和 TABLE 两种输出方式怎么选？

选哪种取决于你“查什么”和“查多久”：

log_output = 'FILE'：适合实时 tail -f 监控，配合 grep -E '(GRANT|REVOKE|INSERT|UPDATE)' 快速抓权限变更或 DML；但无法做条件聚合，日志轮转得靠外部工具（logrotate）
log_output = 'TABLE'：日志存进 mysql.general_log 表（CSV 引擎），可用 SQL 过滤，例如：
SELECT * FROM mysql.general_log WHERE argument LIKE 'GRANT%' ORDER BY event_time DESC LIMIT 10;
但注意：mysql.general_log 不支持索引，数据量大时查询极慢；且 TRUNCATE TABLE 无效，只能 DROP TABLE + CREATE TABLE 重建

为什么 GRANT/REVOKE 语句在日志里找不到？

不是日志没开，而是你没抓对时机或条件：

general_log 只记录被 MySQL 成功接收并进入解析流程的语句。如果语句在客户端被代理改写、被连接池复用旧连接跳过重发、或因语法错误/权限不足被前端拦截，就不会出现在日志里
用 TABLE 模式时，argument 字段可能被截断（受 max_allowed_packet 影响），导致 LIKE 'GRANT%' 匹配失败；建议加 LOWER(argument) 并用 %grant% 宽松匹配
用 FILE 模式时，别只盯 general_log_file 的最后几行——GRANT 常出现在连接建立初期，可能被大量 SELECT 冲到前面去了，得 grep -n 'GRANT' /var/log/mysql/general.log | tail -5 往前翻

永久配置写进 my.cnf 却不生效？

根本问题往往不是配置写错了，而是 MySQL 根本没读到这个文件：

先查真实加载路径：mysqld --help --verbose | grep "Default options"，输出类似 Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
确认你改的是排在最前面的那个文件（通常是 /etc/my.cnf），且 [mysqld] 段落下写了这两行：
general_log = ON
general_log_file = /var/log/mysql/general.log
重启后仍无效？检查 MySQL 启动日志：journalctl -u mysql -n 50 --no-pager，看有没有 Can't open log file 或 unknown variable 报错

真正容易被忽略的是：general_log 记录的是“客户端发来的原始字节流”，它不解析权限、不校验语法、不区分事务边界——这意味着一条 BEGIN; INSERT; UPDATE; COMMIT; 会被记成四行独立事件，而中间任意一步失败，后续语句也不会进日志。想靠它还原完整业务行为，得自己拼时间戳+连接ID+线程ID，不是开个开关就能直接用的。