不能直接mv慢查询日志文件，因MySQL 8.0持续持有文件句柄，mv仅重命名inode，mysqld仍向原fd写入导致内容不可见、磁盘空间不释放，甚至引发同步错误；安全轮转需先SET GLOBAL slow_query_log = OFF，再mv重命名，最后SET GLOBAL slow_query_log_file和slow_query_log = ON。
MySQL 8.0 中不能靠 mv 直接重命名正在写的慢查询日志文件，必须通过运行时控制 + 文件系统操作组合完成，否则会导致日志写入中断、内容丢失或 mysqld 崩溃。
为什么不能直接 mv 慢查询日志文件？
MySQL 8.0 的 slow log 文件是持续追加写入的，内核句柄始终持有该文件。直接 mv 只会改名 inode，但 mysqld 仍往原 fd 写——新文件名下看不到内容，旧文件名虽已不存在，但磁盘空间不会释放（Linux 下表现为“deleted”状态）。更严重的是，某些版本在日志轮转期间触发内部 flush 失败，可能引发 ERROR 1236 (HY000) 类同步异常（尤其在主从架构中）。
- 执行
ls -l /proc/$(pgrep mysqld)/fd/ | grep deleted可验证是否已出现悬挂句柄 -
tail -f看不到新内容 ≠ 日志停了，很可能是写进了被删但未释放的文件 - Windows 下表现不同（文件锁更严格），但同样不可直接重命名
安全迁移并重命名的三步法
核心逻辑：先停写 → 移动+重命名 → 通知 MySQL 切到新路径。全程无需重启服务。
- 第一步：临时关闭日志写入（仅影响新语句，已缓存内容会刷盘）
SET GLOBAL slow_query_log = OFF; - 第二步：用
mv迁移并重命名（确保目标目录存在且mysql用户可写）mv /var/log/mysql/slow.log /var/log/mysql/slow_$(date +%Y%m%d_%H%M%S).log - 第三步：更新配置并重新启用（注意：必须用
SET GLOBAL，不能只改配置文件）SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';SET GLOBAL slow_query_log = ON;
验证是否生效：SHOW VARIABLES LIKE 'slow_query_log_file'; 应返回新路径；再执行 SELECT SLEEP(2); 后检查新文件是否有新增记录。
log_output = 'TABLE' 时怎么处理？
如果当前 log_output 是 'TABLE'（即日志写进 mysql.slow_log 表），那根本不存在“日志文件”需要重命名——此时你面对的是 CSV 引擎表的导出与清空问题，和文件迁移无关。
- 确认方式：
SHOW VARIABLES LIKE 'log_output';返回TABLE或FILE,TABLE - 若只需归档历史数据，用
SELECT * FROM mysql.slow_log INTO OUTFILE '/tmp/slow_log_20261015.csv' FIELDS TERMINATED BY ',';导出 - 导出后清空表：
TRUNCATE TABLE mysql.slow_log;（注意：这不是删除文件，而是清空 CSV 表内容） - 别碰
ALTER TABLE mysql.slow_log ENGINE=InnoDB—— 官方不保证兼容性，重启可能回退
升级后首次迁移要额外检查 secure_file_priv 和目录权限
MySQL 8.0 对日志路径校验更严格，尤其升级后容易沿用旧配置却忽略新版本的权限模型变化。
- 检查
secure_file_priv是否限制了INTO OUTFILE路径（影响导出）：SHOW VARIABLES LIKE 'secure_file_priv'; - 确保
slow_query_log_file所在父目录由mysql用户拥有：chown mysql:mysql /var/log/mysql - 升级后首次启动时，
mysqld --validate-config必须成功，否则日志路径可能被静默降级到数据目录
最易被忽略的一点：log_output 是动态变量，但它的值会影响后续所有日志行为；如果误设为 NONE，哪怕 slow_query_log = ON 也完全不输出——排查时务必优先查这个。
