执行show variables like 'general_log%';可快速确认状态：general_log值为on/off，general_log_file显示路径；off表示未开启，路径异常则配置或权限有误。
怎么快速确认 general_log 是否已开启
直接连上 MySQL 执行这条命令，一眼就能看清状态：SHOW VARIABLES LIKE 'general_log%';。它会返回两行：一行是 general_log（值为 ON 或 OFF），另一行是 general_log_file（告诉你日志写到哪）。如果值是 OFF，说明没开；如果路径是空的或指向一个奇怪的位置（比如 /var/lib/mysql/hostname.log），说明配置不完整或权限不对。
临时开启：不用改配置、不重启，但重启就失效
适合调试时“抓一把现场”，尤其在测试环境或排查偶发问题时非常顺手。执行这两条命令即可：
-
SET GLOBAL log_output = 'FILE';—— 确保日志写进文件（不是表） -
SET GLOBAL general_log = 'ON';—— 真正打开开关
注意：必须用 GLOBAL，会话级（SESSION）设置对 general_log 无效；也别漏掉引号，'ON' 是字符串，不是布尔字面量。开完立刻生效，但 MySQL 服务一重启，又自动关了。
永久开启：改配置 + 权限 + 路径三件事缺一不可
编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，在 [mysqld] 段里加三行：
general_log = ONgeneral_log_file = /var/log/mysql/general.loglog_output = FILE
关键点不是“写了就行”，而是：
- 目录
/var/log/mysql/必须存在，且属主是mysql用户（sudo chown mysql:mysql /var/log/mysql） - 不要指望 MySQL 自动创建日志文件，
touch一下或让 mysqld 启动时自己建（但首次启动失败很常见，不如手动建好） - 如果路径写错（比如拼成
/var/log/mysqll/），MySQL 启动会静默失败——查systemctl status mysql和错误日志才能发现
开了之后马上要做的三件事
通用日志不是“开了就完事”，它会迅速吃光磁盘、拖慢查询、暴露密码——所以启用后必须立刻干预：
- 用
logrotate配置自动轮转，比如每天切一次、保留 7 天：/var/log/mysql/general.log { daily missingok rotate 7 compress } - 检查日志内容是否含明文密码（比如
INSERT INTO users VALUES ('admin', '123456')），一旦有，要么关掉日志，要么用应用层脱敏 - 权限收紧：
sudo chmod 640 /var/log/mysql/general.log，确保只有mysql用户和adm组能读
最常被忽略的是：日志路径不在数据目录下，却忘了给 mysql 用户写权限——结果看起来一切正常，日志就是不写，连错误提示都没有。
