MySQL 8.0错误日志不支持原生按天轮转，需依赖FLUSH ERROR LOGS（8.0.30+引入）配合Shell脚本或logrotate实现；log_error必须为绝对路径，且须用FLUSH LOGS通知MySQL关闭旧句柄并打开新文件，不可用kill -USR1或直接重命名。
MySQL 8.0 错误日志不支持原生按天轮转
MySQL 自身从 8.0 到 8.0.29 都没有 FLUSH ERROR LOGS 命令，它是在 8.0.30 才正式引入的。如果你执行 FLUSH ERROR LOGS; 报错 Unknown command，说明版本不够——别硬套教程，先查 SELECT VERSION();。即使版本达标，log_error 也必须是绝对路径（比如 /var/log/mysql/error.log），设成 stderr 或相对路径会导致命令静默失败。
logrotate 必须配 postrotate + FLUSH LOGS
单纯让 logrotate rename 文件没用：MySQL 进程还握着旧文件描述符，新日志继续写进已重命名的旧文件里，相当于白切。关键动作是通知 MySQL 关闭旧句柄、打开新文件：
-
FLUSH LOGS是通用且安全的方式，兼容所有日志类型（error、slow、general） - 不要用
kill -USR1：MySQL 8.0+ 已废弃该信号对 error.log 的支持，仅对 binlog 有效 - 脚本中加存活判断：
if systemctl is-active --quiet mysql; then mysql -Nse "FLUSH LOGS;" 2>/dev/null || true; fi，否则mysql -e失败会导致轮转后日志丢失 -
create 640 mysql adm权限要匹配实际运行用户：Ubuntu/Debian 通常用adm组，CentOS/RHEL 用mysql组
路径必须和 SHOW VARIABLES LIKE 'log_error' 完全一致
配置前务必确认 MySQL 实际写入位置：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 执行
SELECT @@log_error;或SHOW VARIABLES LIKE 'log_error'; - 注意软链接目标：如果
log_error = /var/log/mysql/error.log，但该路径是软链到/srv/logs/mysql/error.log，logrotate 配置必须写真实目标路径，否则create权限不生效，新日志无法写入 - 避免混用
daily和size 500M：行为不可预测；若防止单文件过大，优先选size，但要知道它只在 logrotate 每日 cron 触发时检查，不是实时监控
binlog 和 error.log 必须分开处理
这是最容易踩的坑：把 binlog 当普通日志交给 logrotate 处理，会直接破坏主从复制。
-
mysql-bin.000xxx类文件由 MySQL 自己管理索引（mysql-bin.index），logrotate 直接删或 rename 会导致SHOW BINARY LOGS显示异常、从库报错Could not find first log file name in binary log index file - binlog 清理只能靠 MySQL 原生机制：
SET PERSIST binlog_expire_logs_seconds = 259200;（3天），或PURGE BINARY LOGS BEFORE '2026-11-01 00:00:00'; - 已存在的几百个 binlog 不会因设置过期参数自动消失，磁盘告急时得手动
PURGE，但必须先核对每台从库的Relay_Master_Log_File，确保不删掉从库还没读完的日志
