什么是慢查询日志？它能帮助定位哪些问题？

说明 slow_query_log、long_query_time、log_queries_not_using_indexes 的作用，以及拿到慢日志后的典型分析路径。

面试记录 2026-10-21

题目：什么是慢查询日志？它能帮助定位哪些问题？

难度：low

标签：db/mysql,db/slow-query

评分：⭐⭐⭐☆☆（3/5）

我的回答

慢查询日志是 MySQL 中用于定位 SQL 执行缓慢问题的。开启后可以设置时间阈值，用是否使用索引来控制记录内容。比如设置超过 500 毫秒的 SQL 就记录到慢查询日志里。后续可以通过命令获取慢查询日志，之前主要是直接在管理后台看，具体命令没印象。它主要定位系统里有哪些 SQL 存在性能问题、哪些 SQL 没有用到索引，然后针对慢 SQL 做优化。

点评

优点：开关、阈值、是否记录未走索引三条主线都在，定位目标明确。

不足：没讲慢日志字段与分析方法；没提 log_output、long_query_time=0 的风险。

补充：重点看 Query_time / Lock_time / Rows_sent / Rows_examined，用 mysqldumpslow 或 pt-query-digest 按总耗时排序；Rows_examined/Rows_sent 比值大说明扫描多，Lock_time 高说明锁等待。

完整讲解

第一部分：知识重点剖析

核心考点是「可观测性入口」：能不能把慢日志变成可执行的优化清单。三个开关——slow_query_log（总开关）、long_query_time（阈值，建议 0.1~0.5s）、log_queries_not_using_indexes（抓未走索引，注意刷屏）。落地三件事：开 log_output=FILE 并轮转、用 pt-query-digest 聚合、按 Rows_examined 与 Lock_time 分类归因。

第二部分：考察方向与延伸递进

• 深度：慢日志与 performance_schema.events_statements_summary_by_digest 的区别与互补
• 广度：慢日志 → 执行计划 → 索引设计 → 表结构治理
• 应用：线上突发慢查询，如何在不改代码的情况下先止血

1. 慢日志里 Rows_examined 很大但 Rows_sent 很小，说明什么？——扫描放大，优先补索引或改写法。
2. long_query_time 设 0 有什么风险？——全量记录，IO 放大，只能临时采样。
3. 为什么慢日志抓不到锁等待？——Lock_time 只统计等表锁/行锁的部分时间，长事务更多体现在业务 RT。

第三部分：面试者参考回答

【一句话结论】 慢查询日志是把「用户说慢」翻译成「哪条 SQL、慢在扫描还是慢在等锁」的第一入口。

【三点展开】 第一，三个开关：总开关、时间阈值、是否记录未走索引，线上阈值一般 0.1~0.5 秒。第二，拿到日志先聚合再排序，按总耗时排，不按单次耗时排。第三，看 Rows_examined 和 Rows_sent 的比值判断是扫描放大，看 Lock_time 判断是不是锁等待。

【一句边界】 慢日志只覆盖执行阶段，连接建立、网络传输、应用侧排队要靠连接池指标和链路追踪补。