慢查询日志开了三天没有记录 long_query_time 是 10

这类问题我又碰上了一次。MySQL 8.0.32 上 slow_query_log 已经是 ON，路径也配了，跑了三天文件一直是空的，业务方明确说有三秒以上的查询，用的是 RDS 自建两套环境对比。

第一反应是「连接池初始化语句把会话级参数覆盖回默认值」，验证下来不成立。

这类报错背后常见的原因有几处，逐个排除就行。long_query_time 设成了十秒，三秒的语句根本达不到记录门槛；log_output 是 TABLE，内容进了 mysql.slow_log 表不在文件里；日志目录没有写权限，写入失败但不报错。

第一件事是确认全局与会话的实际取值

mysql -e "show variables like 'long_query_time'; show variables like 'log_output';"

接着把阈值调到一秒并记录未走索引的语句

mysql -e "set global long_query_time=1; set global log_queries_not_using_indexes=on;"

再往下检查日志目录权限与磁盘余量

ls -l /var/log/mysql/ && df -h /var/log

末了用 performance_schema 交叉验证慢语句

mysql -e "select digest_text,count_star,avg_timer_wait/1e12 s from performance_schema.events_statements_summary_by_digest order by avg_timer_wait desc limit 10;"

恢复的判定其实很直接。调整后一小时内慢日志出现记录，条数与 performance_schema 的统计基本吻合，最长耗时也能对上业务反馈。

提醒一点。long_query_time 支持小数，线上一般设零点五到一；它只对新会话生效，老连接必须重连才会读到新值。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。