1. 慢查询日志是什么，以及为何重要
慢查询日志是 MySQL 中记录执行时间超过设定阈值的 SQL 语句的日志功能，用于定位数据库性能问题。在高并发或大数据量的场景下，慢查询往往成为系统吞吐与响应时间的瓶颈，故而慢查询日志成为运维与开发端关注的重点。通过分析慢查询日志，我们可以快速识别哪些 SQL 影响用户体验、影响资源的瓶颈点，以及需要优化的对象。
核心概念
慢查询日志的核心在于将耗时超阈值的查询记录下来，方便后续分析，帮助团队形成针对性的优化方案。日志中通常包含查询耗时、锁耗、扫描的行数等关键信息，是梳理性能问题的第一手素材。
另外，慢查询日志不仅限于单次极端耗时的查询，结合统计分析也能揭示重复出现的模式，从而对架构与查询设计做出更系统的改进。它是持续性能监控链路的重要一环，也是性能金字塔中的基础工具。
日志字段概览
在典型的慢查询日志中，Query_time 表示查询总耗时，Lock_time 表示等待锁的时间，Rows_examined 表示扫描的行数，Rows_sent 表示返回给客户端的行数。理解这些字段有助于快速判断查询是否因缺少索引、全表扫描或不必要的排序而慢。
通过对这些字段进行比对和聚合，可以发现哪些 SQL 模板是性能问题的主要来源，从而优先优化最具影响力的查询。字段含义清晰，是快速定位的关键线索。
2. 如何开启与配置慢查询日志
在实际环境中，慢查询日志的开启与配置是运维的基础步骤，应结合业务场景与数据库版本谨慎设置。默认情况下，慢查询日志往往是关闭状态，这时需要显式开启以收集数据。
运行时开启与关键参数
为了尽快开始采集数据，可以在不重启数据库的情况下进行设置，避免对线上服务的影响。以下命令用于快速开启与调整阈值：
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5; -- 阈值，单位为秒
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
此处的 long_query_time 设置为 0.5 秒，表示耗时超过 0.5 秒的查询都会被记录。对于短时间内的波动，可以逐步调整为 1 秒以过滤噪声。设置完成后建议在一段时间内观察日志稳定性，再做精细优化。
配置文件持久化设置
若希望长期生效并在服务器重启后依然保持，可在 MySQL 配置文件中持久化配置，避免每次重启手动设置。典型配置如下：
# /etc/mysql/my.cnf 或 /etc/my.cnf
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
log_queries_not_using_indexes = 1
其中 log_queries_not_using_indexes 为可选项，开启后只有未使用索引的查询也会被记录，帮助更全面地发现潜在的索引缺失问题。谨慎开启该项，避免日志量剧增，以免对存储与分析造成压力。
3. 快速定位慢查询的实战思路
在获取到慢查询日志后，接下来要做的是从海量记录中快速提炼高价值的查询模板，形成可执行的优化清单。以下是实战中的高效流程。
基线设定与阈值校准
第一步是建立基线，将阈值与业务波动相结合，确定合理的 long_query_time，避免日志中充斥大量短时波动的记录。通过观察一段时间的日志，可以识别真实的慢查询分布。基线明确后，后续优化才能聚焦重点。
聚合与模板化分析
第二步是将慢查询日志中的重复结构进行模板化，使用分析工具对模板进行聚合统计。这样可以快速识别出高频模式，而不是逐条逐条分析。模板化是提升分析效率的关键。
# 使用 mysqldumpslow 汇总慢查询模板
mysqldumpslow -t 10 -s t /var/log/mysql/slow.log
# 使用 pt-query-digest 提供更全面的报告
pt-query-digest /var/log/mysql/slow.log
诊断与执行计划验证
第三步对高耗时模板进行诊断，逐条使用 EXPLAIN/EXPLAIN ANALYZE 查看执行计划，定位全表扫描、索引缺失、排序与临时表的使用等问题。可通过对比不同执行计划来验证优化效果。
EXPLAIN SELECT /*+ INDEX(orders user_id_idx) */ o.id, o.total
FROM orders o
WHERE o.user_id = ?;第四步结合性能分析视图，在 performance_schema 或 sys 模式中获取全局视图，以便对慢查询的影响面进行评估。通过聚合数据，可以看到最耗时的查询对系统的压力分布。
SELECT digest_text, SUM_TIMER_WAIT/1000000000 AS total_seconds
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 5;4. 常用工具与命令示例
下面列出几种在实践中常用的工具与命令，帮助快速定位和分析慢查询。每种工具都能从不同维度揭示问题所在，便于制定优化方案。
工具一：mysqldumpslow，用于从慢查询日志中提取聚合摘要，快速锁定热点查询模板。
mysqldumpslow -t 20 -s t /var/log/mysql/slow.log
工具二：pt-query-digest，来自 percona toolkit 的强大工具，提供详尽的慢查询分析报告，包含执行时间分布、锁等待、索引覆盖率等维度。
pt-query-digest /var/log/mysql/slow.log
工具三：性能模式与 SYS 框架，结合性能_schema 的视图进行近实时分析，便于持续监控与多维对比。
SELECT digest_text, COUNT_STAR, SUM_TIMER_WAIT/1000000000 AS total_seconds
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;
5. 实战案例：一次慢查询排查完整过程
场景描述：某电商平台的订单查询在高峰期出现明显延迟，慢查询日志记录多条耗时较高的 SQL，影响下游业务与用户体验。本文通过一个完整的排查过程，展示从定位到优化的全链路。
日志定位与复现路径
第一步，通过慢查询日志定位率先关注的高耗时查询模板，确保不会被噪声干扰。记录关键的 Query_time、Rows_examined、Rows_sent 等字段。这是后续优化的落地依据。
tail -n 100 /var/log/mysql/slow.log
第二步，对定位的前几条慢查询使用 mysqldumpslow 汇总模板，确认重复出现的查询模式。
mysqldumpslow -t 5 -s t /var/log/mysql/slow.log
第三步，对代表性慢查询执行计划进行分析，使用 EXPLAIN 检查是否存在全表扫描或索引未覆盖的问题。
EXPLAIN SELECT o.id, o.total
FROM orders o
WHERE o.user_id = ?AND o.created_at > NOW() - INTERVAL 30 DAY;
第四步，根据分析结果进行优化尝试，并通过性能模式视图验证改动是否带来改善。
SELECT digest_text, AVG_TIMER_WAIT/1000000000 AS avg_seconds, COUNT_STAR
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 5;
