慢查询日志未记录变慢查询，主因是long_query_time设置过高、慢日志未启用或路径/权限问题，需验证运行时状态并结合processlist、InnoDB状态、缓存机制及系统IO综合排查。
查询变慢但慢查询日志里没记录，通常不是“没慢”，而是慢日志没捕获到——最常见原因是 long_query_time 设置过高（比如默认 10 秒），或者慢日志根本没开、路径写错、权限不足。也可能是查询耗时在阈值边缘反复波动，或被缓存掩盖了真实延迟。
确认慢日志是否真在工作
别只看配置文件写了没，要验证运行时状态：
- 执行
SHOW VARIABLES LIKE 'slow_query_log';—— 必须是ON，不是1或空字符串 - 执行
SHOW VARIABLES LIKE 'long_query_time';—— 线上建议设为0.5或1，不是默认 10 - 执行
SHOW VARIABLES LIKE 'slow_query_log_file';—— 检查路径是否存在、MySQL 进程是否有写权限（如/var/log/mysql/下目录不可写会导致日志静默失效） - 临时触发一条明确的慢 SQL 测试：
SELECT SLEEP(2);，再立刻查日志文件，看是否落盘
绕过日志，实时抓取正在变慢的查询
慢日志是“事后记录”，而 information_schema.processlist 是“正在发生”：
- 运行
SELECT * FROM information_schema.processlist WHERE TIME > 2 AND COMMAND != 'Sleep';，找出已执行超 2 秒还在跑的语句 - 重点关注
State列：出现Sorting result、Sending data、Copying to tmp table说明卡在排序、结果集传输或临时表阶段 - 搭配
SHOW ENGINE INNODB STATUS\G查看最近的死锁、锁等待、buffer pool 命中率，常能发现隐性瓶颈
检查是不是被缓存干扰了判断
查询“变慢”有时是缓存失效导致的突变，而非 SQL 本身劣化：
- 执行
SELECT @@query_cache_type, @@query_cache_size;（MySQL 5.7 及以前）或SELECT @@performance_schema;（8.0+），确认是否启用了可能误导判断的旧机制 - 用
SELECT SQL_NO_CACHE ...强制跳过查询缓存（5.7 及以前），或在 8.0+ 中关闭query_cache_type=0 - 对比首次执行和重复执行耗时：如果首次很慢、后续极快，大概率是 buffer pool 未预热或磁盘冷读导致
从系统层反向定位 IO 或资源瓶颈
MySQL 慢，不一定是 SQL 的问题：
- 终端运行
top，观察%CPU和%MEM是否打满；若wa（iowait）持续 >20%，说明磁盘在拖后腿 - 执行
iostat -x 1，重点看%util（接近 100% 表示磁盘饱和）、await（单次 IO 平均等待毫秒，>10ms 就需警惕） - 用
df -h检查数据盘是否剩余空间 - 查连接数：
SHOW STATUS LIKE 'Threads_connected';，若接近max_connections上限，新查询会排队等待
