通用查询日志（general_log）默认关闭，临时启用需同步执行SET GLOBAL log_output='FILE'、SET GLOBAL general_log='ON'并确保日志路径权限正确；永久启用须在my.cnf中配置三项参数且手动创建授权目录。
通用查询日志（general_log）不是“配了就能用”，它开不开得成、写不写得出、会不会拖垮服务，全取决于三个动作是否同步到位：设开关、定输出、保路径。生产环境几乎不该开，测试或紧急排查时才临时启用，且必须立刻配套轮转和权限控制。
怎么用 SET 命令临时开启 general_log 并确保日志真写进文件
临时开启最常用，但容易卡在 log_output 默认值上——MySQL 5.7+ 默认是 FILE，但某些发行版或升级后可能变成 TABLE 或 NONE，导致你开了 general_log = ON 却看不到日志文件。
- 先确认当前输出方式：
SHOW VARIABLES LIKE 'log_output';，如果不是FILE，必须显式设置：SET GLOBAL log_output = 'FILE'; - 再打开日志：
SET GLOBAL general_log = 'ON';（注意引号，'ON'是字符串，不是布尔值） -
general_log_file可以不设——默认写入/var/lib/mysql/$(hostname).log，但这个路径常因权限问题静默失败；建议顺手指定：SET GLOBAL general_log_file = '/var/log/mysql/general.log'; - 执行后立刻生效，无需重启；但 MySQL 服务重启后全部丢失
永久配置 general_log 时，my.cnf 里只写参数远远不够
编辑 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 段，光加这三行还不够：
general_log = ON log_output = FILE general_log_file = /var/log/mysql/general.log
真正容易失败的是后续操作：
- 目录必须存在且属主为
mysql用户：sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql - 不要依赖 MySQL 自动创建日志文件，手动 touch 并赋权：
sudo touch /var/log/mysql/general.log && sudo chown mysql:mysql /var/log/mysql/general.log - 路径拼错（比如写成
/var/log/mysqll/）会导致 MySQL 启动静默失败，查systemctl status mysql和错误日志才能定位 - 改完必须重启：
systemctl restart mysqld（CentOS/RHEL）或systemctl restart mysql（Debian/Ubuntu）
为什么开了 general_log 却没生成日志文件或内容为空
这不是配置没生效，而是权限或路径链路断了。常见现象和对应检查点：
- 日志文件存在但大小始终为 0：检查
log_output是否被意外设为TABLE或NONE，执行SHOW VARIABLES LIKE 'log_output';确认 - 日志文件根本没创建：MySQL 进程对父目录无写权限，
ls -ld /var/log/mysql看属主和权限，必须是mysql:mysql且至少有drwxr-xr-x - 日志写了几行就停了：磁盘满或
logrotate误删了正在写的文件（logrotate不能直接 rename 正在追加的 .log），需配置copytruncate或改用create模式 - 看到连接日志但没有 SQL：客户端用了连接池或长连接，实际 SQL 发送频率低；或应用层做了预处理，SQL 在到达 MySQL 前已被过滤
生产环境如果真要全量记录 SQL，general_log = ON 不是首选
它记录每一条到达 MySQL 的语句（含 SELECT、连接、断开），I/O 开销随并发线性增长，QPS 1000 就可能压垮磁盘。更现实的替代路径是：
- 用慢日志代替：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0;（MySQL 5.6.12+ 支持），开销比general_log低 30%–50% - 需要审计级记录时，优先考虑代理层（如 ProxySQL、MaxScale）或网络抓包（tcpdump + pt-query-digest），避开 MySQL 内核路径
- 若坚持用
general_log，必须立刻做三件事：配logrotate（daily + rotate 3）、chmod 640日志文件、扫描日志确认无明文密码（如mysql -uadmin -ptest123）
最常被忽略的一点：日志路径不在数据目录下时，DBA 往往只检查 MySQL 数据目录权限，却忘了给 /var/log/mysql/ 单独授权——结果一切看起来正常，日志就是不写，连错误提示都没有。
