慢查询日志未记录SQL的首要原因是slow_query_log未真正开启为'ON'，其他配置均无效；必须确认其值为字符串'ON'而非1或TRUE，并配合log_output='FILE'或'TABLE'及正确路径权限。
慢查询日志没记你那条“明明很慢”的 SQL，90% 是因为 slow_query_log 根本没真开 —— 其他所有配置都白搭。
确认 slow_query_log 是否真的为 ON
MySQL 不会偷偷启动日志引擎。只要 slow_query_log 不是字符串 'ON'，哪怕 long_query_time=0、log_output='FILE' 全配齐，也一条不写。
- 执行
SHOW VARIABLES LIKE 'slow_query_log';，返回值必须是'ON'（不是1、TRUE或空） - 临时开启用
SET GLOBAL slow_query_log = ON;，但注意：已存在的连接不会生效，得新开客户端验证 - 云数据库（如阿里云 RDS）不支持
SET GLOBAL，必须走控制台或参数模板修改，且需确认是否热生效或需重启 - 配置文件里写
slow_query_log = 1在某些旧版本（如 5.6）可能无效，统一用slow_query_log = ON
log_output 是 NONE 还是 FILE/TABLE？
默认值是 'NONE'，不是 'FILE'。即使 slow_query_log = ON，日志也只“算”该不该记，但无处输出。
- 查当前设置：
SHOW VARIABLES LIKE 'log_output';，必须是'FILE'或'TABLE' - 临时设为文件输出：
SET GLOBAL log_output = 'FILE'; -
slow_query_log_file路径由 MySQL 进程用户（通常是mysql）写入，不是你登录的账号 —— 用ls -ld $(dirname $(mysql -Nse "SELECT @@slow_query_log_file"))看属主和权限 - 磁盘满、SELinux/AppArmor 拦截也会导致静默失败，
df -h和setenforce 0（仅测试）可快速交叉验证
这条 SQL 真的被判定为“慢”了吗？
long_query_time 只对新连接生效，且判定逻辑有隐藏规则：它只算语句真正执行时间，不包括锁等待、调度延迟、复制延迟等。
- 执行
SELECT @@long_query_time;（不是SHOW VARIABLES），确认当前会话实际值；若刚SET过GLOBAL，还得SET SESSION long_query_time = 0.5;才对当前会话有效 -
SELECT SLEEP(2)测试时，系统调度可能导致实际耗时 1.999s，差 1ms 都不记 —— 改用SLEEP(2.1)更可靠 - 未命中索引的查询，默认不进日志，除非开了
log_queries_not_using_indexes = ON -
INSERT/UPDATE/DELETE默认不记录，哪怕执行 10 秒，要捕获就得log_slow_admin_statements = ON - 存储过程内 SQL 默认不单独判定，必须
log_slow_sp_statements = ON
时间戳不准、日志路径错位、权限缺失这些“静默失败”点
日志文件存在但为空，或内容时间明显滞后，往往不是配置漏了，而是底层写入被拦住了。
-
log_timestamps默认是'UTC'，比北京时间晚 8 小时；必须在my.cnf的[mysqld]段加log_timestamps = SYSTEM并重启才生效（SET GLOBAL会报错） -
slow_query_log_file路径在 Windows 下必须用正斜杠/或双反斜杠\，单反斜杠会被当转义符吃掉 - Linux 下目录权限不对（比如属主不是
mysql:mysql）、磁盘满、AppArmor 规则限制，都会导致日志静默丢弃，不报错也不提示 - 用
tail -n 20 /path/to/slow.log直接看最新几行，比猜配置更可靠；如果连文件都没生成，优先查路径权限和log_output
最常被跳过的其实是第一关：没确认 slow_query_log 是否真为 'ON'。后面所有排查，都建立在这个开关打开的前提下。一旦漏掉这步，调再久 long_query_time 也没用。
