MySQL 8.0错误日志不支持原生按天轮转，需用logrotate（配USR1信号）或FLUSH ERROR LOGS（≥8.0.30）配合脚本实现切分、归档与清理，且必须确保log_error为绝对路径、目录存在、mysql用户有写权限。
MySQL 8.0 的错误日志（error log）不支持原生按天轮转，必须靠外部机制触发切分；直接删日志或用 FLUSH LOGS 无效，且可能丢失关键启动/崩溃信息。
确认当前 error log 是否实际写入文件
很多生产环境用 systemd 启动 MySQL，log_error 返回 NULL 或 /dev/null，说明日志被重定向到 journald——此时你配置的轮转脚本根本不会生效。
- 执行
SELECT @@log_error;：若为空或不是绝对路径，先停服务，改配置文件 - 检查启动方式：
systemctl cat mysql看是否用了StandardOutput=journal；若是，需显式设log_error = /var/log/mysql/error.log并确保目录存在、权限为mysql:mysql - 改完必须
systemctl restart mysql，reload不会生效
使用 logrotate 实现安全轮转（推荐方案）
logrotate 是最稳定、可审计、支持压缩和保留策略的方式，但必须配合 USR1 信号通知 mysqld 关闭旧句柄——不能只靠 rename。
- 配置中
postrotate段必须检查/var/run/mysqld/mysqld.pid是否存在，再用kill -USR1 $(cat ...)；若 PID 文件路径不同（如/run/mysqld/mysqld.pid），要同步调整 -
create 0640 mysql mysql必须写对，否则新日志文件权限错误，mysqld 写入失败后静默丢日志 - 测试命令用
logrotate -d /etc/logrotate.d/mysql看模拟输出，确认postrotate命令被调用且无报错
用 FLUSH ERROR LOGS 手动切分（仅限 ≥8.0.30）
FLUSH ERROR LOGS 不是“按天”，而是每次执行都生成带时间戳的新文件（格式为 mysql-error.log.YYYY-MM-DD-HH-MM-SS），适合在运维脚本中控制频率。
- 先查版本：
SELECT VERSION();，低于8.0.30会报Unknown command - 执行前务必确认
log_error是文件路径，且 mysqld 进程有写权限；否则新文件创建失败，旧文件仍被占用 - 它不归档、不压缩、不清理旧文件，必须搭配 shell 脚本做
find /var/log/mysql -name "mysql-error.log.*" -mtime +90 -delete类操作
容易被忽略的权限与路径细节
所有轮转方案失败的根源，90% 出在权限和路径上，不是配置逻辑问题。
-
log_error配置值必须是绝对路径，MySQL 不解析相对路径，也不会自动创建父目录——mkdir -p /var/log/mysql && chown mysql:mysql /var/log/mysql必须手动执行 - 如果用 logrotate，
create指令创建的日志文件属主是mysql，但若 mysqld 运行用户是mysqld（某些 RPM 包行为），会导致写入失败 - SELinux 启用时，
logrotate创建的文件可能继承错误上下文，需加restorecon -Rv /var/log/mysql或在 logrotate 配置中加sharedscripts和prerotate修复
