MySQL慢查询日志未记录的首要原因是未开启slow_query_log，需执行SET GLOBAL slow_query_log = ON或在my.cnf中配置并重启；其次需检查long_query_time精度、从库设置、文件权限、磁盘空间、SELinux限制、代理影响及锁等待时间不计入等问题。
MySQL慢查询日志根本没记录，先确认是否真的开启了
慢查询日志默认是关闭的，很多同学查了半天 slow_query_log_file 路径下空空如也，其实是压根没开。光改 long_query_time 没用，得先让日志引擎跑起来。
执行这条命令看真实状态：
SHOW VARIABLES LIKE 'slow_query_log';
如果返回 OFF，那所有后续配置都白搭。必须显式开启：
-
SET GLOBAL slow_query_log = ON;（会话级无效，必须用GLOBAL） - 更稳妥的是写进配置文件
my.cnf：slow_query_log = ON，然后重启 MySQL（否则服务重启后又变回 OFF） - 注意：有些云数据库（如阿里云 RDS）不支持动态开启，只能通过控制台或参数模板修改
long_query_time 设为 0 还没日志？检查 SQL 执行时间是否被四舍五入
long_query_time 单位是秒，但 MySQL 实际判断时只保留到微秒级，且**对查询耗时不向上取整**。比如设为 0.1，一条耗时 0.099999 秒的查询就不会记——它真就差那 1 纳秒。
常见误判场景：
- 本地测试用
SLEEP(0.1)，结果没进日志：因为SLEEP()的精度受系统调度影响，实际可能只执行了0.099秒 - 设
long_query_time = 0本应记录所有查询，但某些管理语句（如SHOW PROCESSLIST、SELECT 1）仍不会记录——这是 MySQL 内部逻辑，不是 bug - 从库上慢查询日志默认不记录复制线程的 SQL，需额外开启
log_slow_slave_statements
日志文件路径正确但始终为空？确认用户权限和磁盘空间
MySQL 写日志不是以你的登录用户身份，而是以启动 mysqld 的系统用户（通常是 mysql）去操作文件。即使 slow_query_log_file 指向 /var/log/mysql/slow.log，也要检查：
- 目录
/var/log/mysql/是否存在，且mysql用户有写权限（chown mysql:mysql /var/log/mysql） - 磁盘是否已满（
df -h），MySQL 遇到No space left on device会静默失败，不报错也不写日志 - SELinux 或 AppArmor 开启时，可能拦截写入，临时关掉试试：
setenforce 0
用了代理或中间件后慢查询消失？注意日志只记录到达 MySQL 的原始语句
像 ProxySQL、ShardingSphere、甚至某些 ORM（如 Django 的 connection.cursor().execute()）可能把一个逻辑查询拆成多个底层语句，或者加了注释、重写了 SQL。MySQL 日志里记的是最终执行的语句，不是你代码里写的那条。
排查建议：
- 在 MySQL 中开启通用日志（
general_log = ON）对比看：哪些语句真正进了 server，哪些被代理过滤/改写掉了 - 检查
log_output值：如果是TABLE（即写入mysql.slow_log表），记得用SELECT * FROM mysql.slow_log查，别只盯文件 - 某些客户端连接时带了
/*+ MAX_EXECUTION_TIME(1000) */这类 hint，可能触发提前终止，导致未达long_query_time就结束，也不记日志
最常被忽略的一点：MySQL 5.7+ 默认把 long_query_time 的比较基准设为“锁等待时间之后”，也就是语句真正执行的时间，不含等行锁、MDL 锁的时间。如果你的慢其实卡在锁上，它根本不会出现在慢日志里——得去看 information_schema.INNODB_TRX 和 performance_schema.data_lock_waits。
