mysql查询变慢但无慢日志怎么办_mysql性能排查思路

慢查询日志未记录变慢查询，主因是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 上限，新查询会排队等待