slow_query_log显示ON但日志文件为空，主因是log_output未设为FILE、slow_query_log_file路径无写权限或目录不存在、long_query_time未在新会话生效。
slow_query_log 显示 ON 但 slow.log 文件为空
这几乎一定是因为 MySQL 进程没权限往你指定的 slow_query_log_file 路径写入。它不会报错，也不会创建目录，而是静默跳过写日志——哪怕路径里连 /var/log/mysql/ 这个目录都不存在。
检查三件事：
- 执行 SHOW VARIABLES LIKE 'slow_query_log_file'; 看输出路径，比如是 /var/log/mysql/mysql-slow.log
- 登陆服务器，运行 ls -ld /var/log/mysql，确认该目录存在且属主是 mysql 用户（不是 root 或你的登录用户）
- 若目录不存在，手动创建并赋权：sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql
云数据库（如阿里云 RDS、腾讯云 CDB）通常禁用文件输出，只支持写入 mysql.slow_log 表，此时必须同时设 log_output = 'TABLE'，否则日志彻底丢失。
long_query_time 改了但 SELECT SLEEP(1) 不进日志
两个关键点常被忽略：
- long_query_time 是会话级变量，SET GLOBAL long_query_time = 1 只影响新建立的连接；已有连接仍用旧值（比如默认 10 秒）
- SLEEP() 的实际耗时受系统调度影响，可能略低于设定值；MySQL 判断时不向上取整，0.999 秒就卡在阈值外
更可靠的测试方式：
- 先断开当前 MySQL 客户端，重连一次
- 执行 SELECT @@session.long_query_time; 确认当前会话值已更新
- 用 SELECT BENCHMARK(10000000, ENCODE('hello', 'world')); 替代 SLEEP()，它更稳定触发耗时
log_queries_not_using_indexes 导致“不该记的也记了”
这个开关一开，哪怕查询只花了 0.01 秒，只要没走索引且表行数 ≥2，就会进慢日志。线上误开后容易淹没真实慢 SQL。
排查命令：
- SHOW VARIABLES LIKE 'log_queries_not_using_indexes'; —— 若返回 ON，立刻关掉：SET GLOBAL log_queries_not_using_indexes = OFF;
- 同时检查是否启用了 log_slow_admin_statements 或 log_slow_replica_statements，它们会让 ALTER TABLE、复制线程语句也进日志，干扰判断
注意：这些变量在配置文件中设为 0 或 OFF 后，必须重启 MySQL 或执行 FLUSH LOGS; 才能完全清空旧日志缓冲。
日志写了但你看不见：log_output 和表结构问题
如果 log_output = 'TABLE'（默认值之一），日志不会写文件，而是插入 mysql.slow_log 表。但这个表可能：
- 根本不存在（首次启用慢日志时未自动建表）
- 存在但引擎是 CSV（旧版本默认），导致写入失败且无提示
- 表满了或磁盘满，INSERT 静默失败
验证方法：
- SHOW VARIABLES LIKE 'log_output'; —— 若含 TABLE，再查：SELECT COUNT(*) FROM mysql.slow_log;
- 若报错 Table 'mysql.slow_log' doesn't exist，运行 INSTALL PLUGIN slow_log SONAME 'mysql_server.so';（8.0.26+ 可能需先确认插件状态）
- 更稳妥的做法是显式设为文件输出：SET GLOBAL log_output = 'FILE';，再确认 slow_query_log_file 路径可写
最隐蔽的坑是：某些容器化部署中，mysql 用户对挂载卷没有写权限，或者 SELinux/AppArmor 拦截了写操作，临时用 setenforce 0 测试一下就能快速定位。
