开启慢查询日志本身不拖慢mysql，性能下降主因是磁盘i/o过载、long_query_time设过低或log_queries_not_using_indexes误用；应合理配置阈值、优化日志输出方式并结合explain分析。
slow_query_log=ON 本身不直接拖慢实例
开启慢查询日志不会让单条 SQL 变慢，MySQL 是在语句执行结束后才判断是否记录——这个判断开销极小。性能下降的根源几乎总是日志写入方式或阈值配置不当导致的副作用。
log_output=FILE 且磁盘 I/O 不堪重负
当 log_output 设为 FILE（默认），所有达标 SQL 都要同步写入磁盘文件。如果磁盘本身已高负载（如机械盘、共享云盘、日志目录所在分区被其他进程占满 I/O），就会成为瓶颈。
- 检查磁盘使用率：
df -h和iostat -x 1看%util和await - 确认日志路径不在系统盘或数据库数据盘同一物理设备上
- 避免把
slow_query_log_file指向 NFS 或低性能网络存储 - 临时缓解：设
log_output=TABLE，日志写入mysql.slow_log表（仍需注意该表所在缓冲池压力）
long_query_time 设得太低，日志量爆炸
设成 0.1 或 0 后，连 SELECT 1 都可能进日志。尤其在高 QPS 场景下，每秒几百上千条日志写入，I/O 和解析开销会反噬实例。
- 生产环境建议从
1.0起步；若想抓更多线索，优先用log_queries_not_using_indexes=ON+long_query_time=2组合 - 别长期开着
long_query_time=0：它记录所有查询，包括预处理语句、心跳包等干扰项 - 用
mysqldumpslow -s c -t 5 /path/to/slow.log快速看调用最频繁的几条，比盯单条耗时更有价值
log_queries_not_using_indexes=ON 引发误伤
这个开关一开，所有没走索引的 SELECT 都会被记入，哪怕它是 SELECT COUNT(*) FROM config 这种毫秒级小表查询。结果就是日志文件体积暴涨、磁盘写满、解析工具卡死。
- 它不是“查慢 SQL”的开关，而是“查漏建索引”的开关——用途不同，别混用
- 上线前可临时开它扫一遍，但上线后务必关掉，除非你真在做索引审计
- 真正该优先分析的是
long_query_time触发的语句，再对它们跑EXPLAIN看type是否为ALL或index
最常被忽略的一点：慢日志本身不优化查询，它只暴露问题。开了日志却不去 EXPLAIN 那些高频慢 SQL，或者加了索引却不验证 key_len 和 rows 是否下降，日志再全也白搭。
