慢查询日志未记录SQL，90%因slow_query_log为OFF；必须先执行SHOW VARIABLES LIKE 'slow_query_log'确认返回'ON'，再检查log_output是否为'FILE'或'TABLE'，否则所有配置均无效。
慢查询日志没记录 SQL，90% 是因为 slow_query_log 还是 OFF —— 其他所有配置都白搭。
确认 slow_query_log 真的开着了吗？
很多人改了 long_query_time 就以为万事大吉，但 MySQL 根本不启动日志引擎，自然一条都不写。这不是 bug，是设计逻辑：开关没开，阈值再小也没意义。
- 执行
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 是不是设成了 FILE？
默认值是 'NONE'，不是 'FILE'。即使 slow_query_log = ON，日志也只会“计算”是否该记，但不输出到任何地方。
- 查当前设置：
SHOW VARIABLES LIKE 'log_output';，必须是'FILE'或'TABLE'（后者需确保mysql.slow_log表存在且可写） - 临时设为文件输出：
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_slow_slave_statements影响
为什么 SELECT COUNT(*) 明显很慢却没进日志？
这是典型误判场景：InnoDB 扫全表计数时，rows_examined 可能远超 min_examined_row_limit，但若该参数设得太高（比如 1000），而实际扫描行数刚好卡在阈值下，就会被跳过。
- 查当前值：
SELECT @@min_examined_row_limit; - 这个参数和
long_query_time是“与”关系：必须同时满足「耗时超阈值」且「扫描行数 ≥ 该值」才记录 -
SELECT COUNT(*)在无二级索引时走聚簇索引，rows_examined= 表总行数 —— 如果表只有 500 行，min_examined_row_limit = 1000，那再慢也不记 - 源码里
log_slow_applicable()函数明确做了这层判断，不是配置遗漏，是逻辑过滤
最易被忽略的点：日志里没出现的慢 SQL，往往不是没发生，而是根本没通过这三重校验——开关、输出、判定。先盯死 slow_query_log 和 log_output 的实时值，比调 long_query_time 重要十倍。
