慢查询日志是定位执行效率低下的SQL语句的常用手段，它通过记录执行时间超过阈值的SQL，让DBA能够精准锁定数据库性能瓶颈，从而进行针对性优化。
为什么慢查询日志是数据库调优的关键
数据库性能下降，通常表现为页面加载缓慢、接口超时，行业共识认为，慢查询日志是诊断这类问题的第一选择，它记录了所有执行时间超过设定阈值的SQL语句，包括查询、更新、删除等操作，通过分析这些语句，你能快速找到哪些SQL消耗了过多资源，是缺少索引、数据量过大,还是查询设计不合理。
据统计，大部分数据库性能问题都可以通过慢查询日志找到线索，相比实时监控工具，慢查询日志提供的是历史记录，方便你回溯问题发生时的SQL执行情况，它不需要安装额外代理，只要在数据库配置中开启，就能持续收集数据,控制好对性能的影响。
MySQL慢查询日志怎么开启？详细步骤
开启慢查询日志是MySQL数据库调优的常规操作，不同版本MySQL的默认配置不同，但开启逻辑一致，下面以MySQL 5.7和8.0为例,给出具体操作步骤。
临时开启（重启后失效）：
- 连接MySQL，执行
SET GLOBAL slow_query_log = ON; - 同时设置
SET GLOBAL long_query_time = 2;（单位秒,记录执行时间超过2秒的SQL） - 查看状态：
SHOW VARIABLES LIKE 'slow_query_log%';
永久开启（写入配置文件）：
- 编辑MySQL配置文件（my.cnf或my.ini），在[mysqld]段下添加：
slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2 log_queries_not_using_indexes = 1 - 重启MySQL服务，执行
SHOW VARIABLES LIKE 'slow_query%';确认配置生效。
在云数据库上开启慢查询日志：
- 简米云RDS：默认开启慢查询，但阈值可能为1秒，需在控制台参数设置中调整
long_query_time，找到slow_query_log参数设为ON。 - 酷番云CDB：默认开启，慢查询日志保存在
/data/mysql/slow.log,通过控制台可下载。 - 华为云GaussDB：类似,通过参数组调整。
慢查询日志配置参数详解
配置参数直接影响慢查询日志的收集范围和对性能的影响，这里详细解释几个关键参数,帮助你按需调整。
- long_query_time：设置阈值，默认10秒，建议根据业务压力设为2秒或1秒，如果业务以微服务为主，可设为0.5秒。
- log_queries_not_using_indexes：记录全表扫描但速度可能不慢的查询，这个参数很有用，它帮你发现索引缺失，但开启后，日志量会明显增加,需要权衡。
- log_slow_admin_statements：记录慢的管理语句，如创建索引、修改表结构，如果这些操作很少，可以开启；如果频繁,可能会干扰分析。
- min_examined_row_limit：设置检查行数下限，低于该行数的查询不被记录，用于过滤小表扫描，但建议谨慎使用,可能遗漏问题。
优化配置建议：
- 生产环境：slow_query_log=1，long_query_time=2，开启
log_queries_not_using_indexes，不开log_slow_admin_statements。 - 开发环境：long_query_time=0.5，开启所有参数,便于发现潜在问题。
- 使用
pt-query-digest定期分析日志，并归档历史日志,避免磁盘满。
慢查询日志分析工具对比：哪种更适合你？
原始慢查询日志是文本格式，直接阅读效率低，你需要借助工具归类分析，这里对比两款主流工具：pt-query-digest（Percona Toolkit）和MySQL自带的mysqldumpslow。
mysqldumpslow：
- 自带,无需额外安装。
- 支持按平均时间、执行次数、返回行数等排序。
- 输出分组统计，能看到类似SQL的摘要,但缺少查询计划细节。
- 适合简单查看,快速定位问题。
pt-query-digest：
- 功能强大，分析后生成详细报告，包含SQL指纹、执行时间分布、等待事件、索引建议等。
- 支持多种输出格式（文本、HTML、JSON）。
- 能够识别相似查询并合并,分析效率高。
- 提供排名，按总时间、平均时间等排序,方便你优先处理最严重的查询。
使用示例：
- 分析日志：
pt-query-digest /var/log/mysql/slow.log > report.txt - 按时间范围分析：
pt-query-digest --since '2026-01-01 00:00:00' --until '2026-01-02 00:00:00' slow.log - 输出HTML报告：
pt-query-digest --output=html slow.log > report.html
对比表格：
| 维度 | mysqldumpslow | pt-query-digest |
|---|---|---|
| 安装方式 | MySQL自带 | 需安装Percona Toolkit |
| 分析深度 | 基础统计 | 深入SQL指纹、执行计划 |
| 输出格式 | 文本 | 文本、HTML、JSON |
| 适用场景 | 快速查看 | 日常性能调优、报告生成 |
选择建议：如果只做一次快速排查，直接使用mysqldumpslow，但如果需要持续优化数据库性能，或者需要为团队提供报告，pt-query-digest是更好的选择，它虽然需要安装，但分析结果更全面,能节省大量手动分析时间。
如何通过慢查询日志优化SQL语句？实战案例
拿到慢查询日志后，你需要分析具体SQL，下面以华东地区某电商平台的订单查询为例,说明优化流程。
慢查询日志优化SQL语句的实战技巧
索引缺失导致全表扫描
慢查询日志记录了一条SQL：SELECT FROM orders WHERE status = 1 AND create_time > '2026-01-01' ORDER BY id DESC LIMIT 100;
耗时5秒，返回100行，分析后发现status和create_time字段没有索引,导致全表扫描。
优化步骤：
- 使用EXPLAIN查看执行计划,确认扫描行数。
- 创建复合索引：
ALTER TABLE orders ADD INDEX idx_status_time (status, create_time); - 重新执行，查询时间降到02秒。
- 如果业务允许，将
SELECT改为只取需要的字段,减少回表。 - 考虑分页优化，避免深度分页,使用游标或子查询。
深度分页导致慢查询
慢查询日志：SELECT FROM users ORDER BY id ASC LIMIT 100000, 20; 耗时8秒，优化方法：使用主键过滤，改为SELECT FROM users WHERE id > 100000 ORDER BY id ASC LIMIT 20;，或者使用子查询，改写后耗时
01秒。
另一个常见原因：函数导致索引失效
比如WHERE DATE(create_time) = '2026-01-01'，即使create_time有索引，也因函数作用而失效，改写为WHERE create_time >= '2026-01-01' AND create_time < '2026-01-02'即可利用索引。
优化长SQL：如果日志中有大量嵌套子查询或临时表操作，可以拆分SQL，或使用JOIN替代子查询，但要注意，并非所有子查询都慢,需要结合EXPLAIN和实际数据测试。
定期监控：优化后，将慢查询日志持续开启，观察新日志中是否还有同类问题，如果出现新的慢查询,重复上述步骤。
慢查询日志只是定位问题的起点，真正解决问题需要结合索引优化、SQL改写、表结构设计等综合手段，持续监控，不断调整,才能让数据库始终保持高效。
慢查询日志常见问题解答
Q1：开启慢查询日志会影响数据库性能吗？
A：会，但影响很小，慢查询日志本身就是写入操作，每次记录慢查询需要写磁盘，如果慢查询很多，日志写入频繁，可能对IO有一定压力，建议将日志文件放在独立的磁盘或固态硬盘，并设置参数long_query_time避免记录过多SQL，通常情况下,开启慢查询日志对性能的影响可以忽略不计。
Q2：慢查询日志优化是否必须购买商业工具？
A：不需要，开源工具如pt-query-digest完全免费，功能强大，可以满足大部分分析需求，商业工具提供更多可视化图表和报警功能，但价格通常按数据库节点计算，从几千到几万不等，对于大多数场景,免费工具足以应对慢查询日志的日常分析。
Q3：如何清理慢查询日志，避免磁盘无限增长？
A：慢查询日志不会自动清理，你可以通过以下方式管理：1）在日志轮转工具中配置，如Linux的logrotate，定期压缩归档，2）使用pt-query-digest分析后，定期清空日志文件，例如echo > /var/log/mysql/slow.log，但注意需要确保MySQL用户有权限，或者使用SET GLOBAL slow_query_log = OFF;后清空再开启，3）设置slow_query_log_file为固定大小，但MySQL不提供自动轮转,建议结合外部脚本。