mysql 5.7+ 启用 general_log 需在 my.cnf 的 [mysqld] 段配置 general_log = on 和 general_log_file = /var/log/mysql/general.log，确保路径权限正确；动态开启用 set global general_log = 'on'，但仅对新连接生效、重启失效且性能影响大。
MySQL 5.7+ 启用 general_log 的配置项写法
通用查询日志默认是关闭的，必须显式开启 general_log 并指定日志输出目标。直接在 my.cnf（或 my.ini）的 [mysqld] 段落里加两行即可生效：
-
general_log = ON—— 必须设为ON（不能写1或TRUE，部分旧版本虽兼容，但官方文档明确要求字符串值） -
general_log_file = /var/log/mysql/general.log—— 建议写绝对路径；若不指定，MySQL 会按hostname.log规则生成在数据目录下，容易和错误日志混在一起
注意：Linux 下确保 MySQL 进程对目标目录有写权限，否则启动失败且报错 Can't open the mysql.plugin table 这类误导性信息——实际是日志文件创建失败。
运行时动态开启 general_log 的风险点
可以用 SET GLOBAL general_log = ON 临时启用，但存在几个关键限制：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 仅对新建立的连接生效；已存在的连接不会自动记录后续语句
- 日志文件名不会自动更新——如果之前没配
general_log_file，它会沿用启动时默认的文件名（比如localhost.log），且无法通过SET修改 - 重启后失效：该设置不持久，MySQL 服务重启后恢复为配置文件中的值
- 性能影响明显：每条客户端请求（包括 ping、use db 等）都会写磁盘，高并发下 I/O 压力陡增，不建议在生产环境长期开启
验证 general_log 是否真正生效
别只看 SHOW VARIABLES LIKE 'general_log' 返回 ON 就以为完事了。要确认三点：
- 检查日志文件是否存在且有内容：
tail -f /var/log/mysql/general.log，然后执行一条SELECT 1，看是否实时追加 - 留意时间戳格式：MySQL 8.0+ 默认用微秒级时间戳（如
2024-05-20T14:22:33.123456），而 5.7 是秒级（2024-05-20T14:22:33），避免误判为空 - 如果日志文件始终为空，先查 MySQL 错误日志（
error_log），常见原因是权限不足或磁盘满，而不是配置写错
停用 general_log 时的清理习惯
停用后日志文件不会自动删除或截断，得手动处理：
- 停用前建议先
SET GLOBAL general_log = OFF，再改配置文件并重启，避免中间窗口期漏记录 - 日志文件可能极大（尤其忘了关），用
truncate -s 0 /var/log/mysql/general.log清空比删重建更安全（防止应用还在 fd 持有句柄） - 如果用
general_log_file指向 syslog 或管道（极少见），停用后需额外检查系统日志服务状态
最常被忽略的是：日志路径的父目录权限、SELinux（RHEL/CentOS）上下文、以及 MySQL 用户对文件的 ownership——这些不解决，哪怕配置全对，也只会静默失败。
