mysql错误日志路径需在my.cnf的[mysqld]段落配置log_Error参数，如
log_error = /var/log/mysql/error.log，并确保MySQL用户有写权限，修改后必须重启服务生效。
MySQL 错误日志路径怎么改
错误日志（error_log）默认不启用，或由系统自动指定位置（如 /var/log/mysqld.log 或 /var/lib/mysql/hostname.err），具体取决于安装方式和操作系统。要显式控制路径，必须在配置文件中设置 log_error 参数。
- 编辑
my.cnf（通常位于/etc/my.cnf或/etc/mysql/my.cnf），在[mysqld]段落下添加：log_error = /var/log/mysql/error.log - 确保 MySQL 进程对目标目录有写权限（例如
chown mysql:mysql /var/log/mysql） - 注意：不能只写文件名（如
log_error = error.log），否则会写入数据目录，且重启后可能因权限或路径不存在而静默失败 - 修改后需重启 MySQL（
systemctl restart mysqld或service mysql restart），仅重载配置（mysqladmin reload）不生效
通用查询日志和慢查询日志开关与路径
这两类日志默认关闭，开启后路径由 general_log_file 和 slow_query_log_file 控制，但必须配合对应开关使用，缺一不可。
- 启用通用查询日志：
general_log = ON
general_log_file = /var/log/mysql/general.log - 启用慢查询日志：
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1.0 -
long_query_time单位是秒，支持小数；设为 0 表示记录所有查询（慎用，I/O 压力大） - 日志文件路径若未指定，默认生成在
datadir下，文件名分别为hostname.log和hostname-slow.log，容易和错误日志混淆 - 这些参数可在线动态设置（如
SET GLOBAL general_log = ON），但仅影响运行时，不持久化——必须写入配置文件才能保证重启后有效
二进制日志（binlog）路径和命名规则
binlog 路径由 log_bin 决定，它不仅是路径，还隐含基础文件名前缀；MySQL 会自动追加编号（如 mysql-bin.000001）和索引文件（mysql-bin.index）。
- 正确写法：
log_bin = /var/log/mysql/mysql-bin（结尾不带扩展名，也不带数字）
- 错误写法：
log_bin = /var/log/mysql/mysql-bin或
log_bin = /var/log/mysql/—— 后者会导致 MySQL 启动失败并报错
Failed to open log file - binlog 路径不能与
datadir相同（尤其在启用innodb_file_per_table时），否则可能引发权限冲突或备份工具误判 - 如果只想控制存储位置而不改变前缀名，可配合
log_bin_basename（MySQL 8.0.28+），但多数生产环境仍用log_bin即可
日志文件权限和轮转注意事项
MySQL 以运行用户（通常是 mysql）身份写日志，但日志轮转（logrotate）常以 root 执行，两者权限不一致极易导致写入中断。
- 轮转配置中必须包含
create 640 mysql mysql，否则新日志文件属主为 root，MySQL 无法继续写入 - 避免使用
copytruncate：它会清空原文件，但 MySQL 的文件描述符仍指向已被截断的 inode，导致日志“消失”却无报错 - binlog 不受 logrotate 管理，应使用
PURGE BINARY LOGS或expire_logs_days控制生命周期 - 查询类日志（general / slow）没有内置轮转机制，必须靠外部工具；若长期开启又不轮转，单个文件可达数十 GB，影响
grep和分析效率
MySQL 日志路径看似只是配个字符串，实际牵扯权限、启动顺序、轮转策略和运维习惯。最容易被忽略的是：错误日志路径修改后未验证是否真正写入，以及 binlog 路径末尾多加了个 .log 导致服务起不来——这两个问题在线上都曾造成过长达数小时的排查延误。