slow_query_log显示on但日志文件为空，主因是log_output未设为file；需执行show variables like 'log_output'确认，若非file则须设为file并确保路径权限正确、long_query_time精度匹配。
slow_query_log 显示 ON 但日志文件空——检查 log_output 是否为 FILE
MySQL 升级后常见问题：执行 SHOW VARIABLES LIKE 'slow_query_log'; 返回 ON，路径也对，日志文件却始终为空。根本原因常是 log_output 没设成 FILE。
MySQL 5.6+ 默认 log_output 可能是 TABLE（写入 mysql.slow_log 表）或 NONE（完全不输出），哪怕 slow_query_log=ON 也白搭。
- 查当前输出方式：
SHOW VARIABLES LIKE 'log_output';—— 若结果不是FILE，就不可能生成日志文件 - 临时生效（重启失效）：
SET GLOBAL log_output = 'FILE'; - 永久生效：在
my.cnf的[mysqld]下加一行：log_output = FILE，再重启 MySQL - 注意：如果同时开了
general_log，它也受log_output控制，别只盯慢日志
long_query_time 设为 0 还没记录？确认查询真实耗时是否被截断
升级后部分版本（如 8.0.33+）对 long_query_time 的判断更严格：它只保留微秒精度，且**不向上取整**。设成 0.1，一条耗时 0.099999 秒的查询就直接跳过，不会进日志。
这不是 bug，是设计行为。线上排查时容易误判“阈值没生效”，其实是 SQL 刚好卡在边界下。
- 用
SELECT @@long_query_time;确认当前会话看到的值（注意：SET GLOBAL不影响已有连接） - 测试必须用新连接，或显式执行
SET SESSION long_query_time = 0.1; - 最稳妥的验证方式：
SELECT SLEEP(2);，然后立刻tail -f日志文件看是否落盘 - 若仍无记录，说明问题不在阈值，而是前面的开关或输出路径环节
升级导致 slow_query_log_file 路径失效——权限与 SELinux 重置
MySQL 升级常伴随用户/组变更（比如从 mysql:mysql 改成 mysqld:mysqld），旧日志路径即使存在，也可能因权限丢失而静默失败——不报错，也不写入。
尤其在 CentOS/RHEL 或启用了 SELinux 的系统上，升级后策略可能重置，导致写日志被拦截。
- 检查路径权限：
ls -ld $(mysql -Nse "SELECT @@slow_query_log_file;")，确认属主和写权限匹配当前 MySQL 进程用户 - 临时验证 SELinux 影响：
sudo setenforce 0，再触发慢查询看日志是否出现 - 磁盘空间也要看：
df -h $(dirname $(mysql -Nse "SELECT @@slow_query_log_file;"))，满盘时 MySQL 会停写且不提示 - 云数据库（如阿里云 RDS）升级后参数可能被重置，需进控制台核对“慢日志开关”和“阈值”是否仍为开启状态
为什么 FLUSH LOGS 后还是没新内容？确认日志缓冲未被绕过
MySQL 对慢查询日志默认使用行缓冲（line-buffered），不像错误日志那样实时刷盘。升级后某些版本或配置组合可能导致缓冲延迟加剧，甚至在崩溃前丢失最后几条记录。
这不是配置错误，而是日志机制本身特性。你执行 FLUSH LOGS; 只能强制轮转并刷当前缓冲，但无法保证“刚发生的慢查询”一定已进入缓冲区。
- 不要依赖
FLUSH LOGS来验证是否开启成功，它只是辅助手段 - 真正可靠的验证链是：
slow_query_log=ON→log_output=FILE→slow_query_log_file可写 →long_query_time设置合理 → 新连接下跑SLEEP(2) - 如果日志文件存在但内容陈旧，优先怀疑 MySQL 进程是否真的在用这个配置启动（
ps aux | grep mysql看启动命令里有没有--defaults-file覆盖了my.cnf）
升级后的慢日志失效，九成问题出在 log_output 和权限这两处。很多人盯着 slow_query_log 是 ON 就以为万事大吉，却忽略了它只是总闸，后面还连着输出通道、路径权限、精度截断三道关卡。漏掉任意一环，日志都安静得像没开过。
