mysql升级后日志路径和配置必须显式重设：error log和slow-query-log-file需确保目录存在并授权；log-bin迁移要复制旧文件并避免直接删除；gtid模式下purge需谨慎；废弃参数如log_warnings须替换为log_error_verbosity；升级后必须运行mysqld --validate-config验证配置。
MySQL 升级后，日志文件不能直接沿用旧路径或配置——尤其是 error log、slow-query-log-file、log-bin 这三类，稍有疏忽就会导致服务启动失败、复制中断或日志丢失。
错误日志和慢查询日志迁移：权限和路径必须显式重设
升级后 MySQL 仍会尝试读取原配置中的日志路径，但若目标目录不存在、权限不对，或配置被新版本忽略（比如 Windows 下 my.ini 未被加载），mysqld 可能静默降级到默认路径（如 /var/lib/mysql/hostname.err），而你完全不知道它没写进你指定的位置。
- 编辑
my.cnf，在[mysqld]段明确写出：log-error = /var/log/mysql/error.log和slow-query-log-file = /var/log/mysql/slow.log - 确保目录存在：
mkdir -p /var/log/mysql，并赋权：chown mysql:mysql /var/log/mysql - 不要依赖“自动继承”——哪怕旧版一直工作，升级后首次启动也建议加
--log-error-verbosity=3查看实际日志输出位置
二进制日志迁移：路径变更需重启，且旧 binlog 不可直接删除
log-bin 是最易出问题的日志项。MySQL 8.0+ 对路径合法性校验更严格，若新路径含空格、软链接未解析、或父目录无 x 权限，启动直接报错 Failed to open log file；更麻烦的是，改完路径重启后，MySQL 会从 mysql-bin.000001 重新编号，旧 binlog 文件不会自动迁移，也不再被识别。
- 正确做法是：先停库 → 复制全部
mysql-bin.*和mysql-bin.index到新路径 → 修改配置log-bin = /new/path/mysql-bin→ 启动 - 若只是换磁盘、不保留旧日志，也必须用
PURGE BINARY LOGS BEFORE '2026-01-01'清理，而非rm删除文件，否则SHOW BINARY LOGS仍显示已删文件，且可能引发复制异常 - GTID 模式下，主库 purge 掉的 binlog 若从库还没消费，
Seconds_Behind_Master会卡死，并报错The slave requires GTIDs that the master has purged—— 此时只能重建从库
升级后日志相关配置项是否还有效？必须逐条验证
MySQL 5.7 升 8.0 或 8.4 时，不少日志行为参数已被移除或语义变更。例如 log_warnings 在 8.0 中废弃，改用 log_error_verbosity；expire_logs_days 虽仍可用，但优先级低于 binlog_expire_logs_seconds，且后者默认为 2592000（30 天），若没显式设置，可能比你预期多留一周日志。
- 运行
mysqld --verbose --help | grep -E "(log|error|slow|binlog)"查当前版本真正支持的参数名 - 检查旧配置中是否有
log-output（8.0+ 已移除）、general_log_file（仍可用但默认关闭）等易被忽略的开关 - 特别注意
sql_mode升级后新增STRICT_TRANS_TABLES，可能导致慢查询日志里突然出现大量Warning级别记录，撑爆磁盘
最容易被跳过的点是：升级后没跑 mysqld --validate-config，就直接 systemctl restart mysqld。结果服务起不来，错误日志却根本没写——因为连 log-error 路径都错了。务必把验证当成上线前最后一步，而不是“应该没问题”的假设。
