在数据库性能优化领域，慢查询日志是定位性能瓶颈的核心工具。通过记录执行时间超过阈值的SQL语句，开发人员和DBA可精准识别低效查询，针对性优化索引、SQL逻辑或数据库设计。本文ZHANID工具网将系统梳理MySQL慢查询日志的开启方法、配置参数、分析工具及实战案例，为性能优化提供可落地的技术方案。
一、慢查询日志核心参数详解
MySQL通过三个核心参数控制慢查询日志行为，需根据业务场景灵活配置：
slow_query_log
控制日志开关状态，取值范围：SET GLOBAL slow_query_log = ON; -- 临时生效，重启失效
0/OFF：关闭日志（默认值）1/ON：开启日志 动态修改示例：long_query_time
定义慢查询阈值（单位：秒），默认值为10秒。生产环境建议调整为1-5秒，例如：SET GLOBAL long_query_time = 2; -- 记录执行超2秒的查询
精度说明：MySQL 5.1+版本支持微秒级精度（如
2.500000秒）。log_queries_not_using_indexes
控制是否记录未使用索引的查询，默认关闭。排查索引问题时建议临时开启，但需配合log_throttle_queries_not_using_indexes限制日志频率，避免日志爆炸式增长。
二、慢查询日志开启方法
方法1：配置文件永久生效（推荐）
修改配置文件
在my.cnf（Linux）或my.ini（Windows）的[mysqld]段添加：[mysqld] slow_query_log = ON slow_query_log_file = /var/log/mysql/mysql-slow.log # 日志路径需MySQL用户可写 long_query_time = 2 log_queries_not_using_indexes = ON # 可选：记录未使用索引的查询
重启服务生效
Linux系统：
sudo systemctl restart mysql
Windows系统：
net stop mysql && net start mysql
方法2：动态命令临时生效
适用于快速测试或临时排查场景：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2; SET GLOBAL log_queries_not_using_indexes = ON;
注意：动态配置在MySQL重启后失效，需同步修改配置文件。
三、慢查询日志分析工具
1. 基础工具：mysqldumpslow
MySQL自带命令行工具，适合快速统计高频慢查询。
常用命令示例：
# 按总执行时间排序，显示前10条 mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log # 按查询次数排序，显示最频繁的5条 mysqldumpslow -s c -t 5 /var/log/mysql/mysql-slow.log # 过滤包含"SELECT * FROM orders"的查询 mysqldumpslow -g "SELECT \* FROM orders" /var/log/mysql/mysql-slow.log
输出字段解析：
Count: 5 Time=3.50s (17.50s) Lock=0.00s (0.00s) Rows=1.0 (5.0) SELECT * FROM users WHERE created_at > '2023-08-20';
Count：查询执行次数Time：平均执行时间（括号内为总时间）Lock：平均锁等待时间Rows：平均返回行数（括号内为总行数）
2. 进阶工具：pt-query-digest（Percona Toolkit）
提供更详细的查询分析报告，支持时间范围过滤、HTML格式输出等功能。
安装与使用：
# CentOS安装示例 yum install percona-toolkit # 生成文本报告 pt-query-digest /var/log/mysql/mysql-slow.log # 生成HTML报告（可视化分析） pt-query-digest --report-format html /var/log/mysql/mysql-slow.log > slow_report.html
关键指标解读：
Query_time distribution：执行时间分布（如95%的查询在1秒内完成）Rank：查询排名（按总执行时间）Response：平均/最大响应时间Throughput：每秒执行次数
四、慢查询优化实战案例
案例1：电商平台订单统计接口优化
背景：某电商平台订单统计接口响应时间超5秒，涉及2000万行订单表的复杂聚合查询。
优化步骤：
开启慢查询日志
在my.cnf中配置：slow_query_log = ON long_query_time = 2 slow_query_log_file = /var/log/mysql/slow.log
分析日志定位瓶颈
使用pt-query-digest生成报告，发现以下慢查询：SELECT oi.product_id, SUM(oi.quantity) AS total_sold FROM order_item oi JOIN `order` o ON oi.order_id = o.id WHERE o.status = 'COMPLETED' AND o.created_at BETWEEN '2023-01-01' AND '2023-06-30' GROUP BY oi.product_id;
EXPLAIN分析结果：
+----+-------------+-------+------------+------+---------------+------+---------+----------------------+-------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+------+---------+----------------------+-------+----------+-------------+ | 1 | SIMPLE | o | NULL | ALL | idx_status | NULL | NULL | NULL | 2000000 | 10.00 | Using where | | 1 | SIMPLE | oi | NULL | ref | idx_order_id | idx_order_id | 4 | test.o.id | 500000 | 100.00 | Using index | +----+-------------+-------+------------+------+---------------+------+---------+----------------------+-------+----------+-------------+
问题：
order表全表扫描（type=ALL），扫描行数达200万。优化方案
添加组合索引：
ALTER TABLE `order` ADD INDEX idx_status_created_at (status, created_at);
优化后EXPLAIN结果：
type: range, key: idx_status_created_at, rows: 50000, Extra: Using where; Using index
效果：查询时间从5秒降至500毫秒。
案例2：读写分离与分区表优化
背景：高并发读请求导致主库负载过高，需通过读写分离和分区表提升性能。
优化步骤：
配置读写分离
使用Sequelize+XORM实现读请求路由到从库：const sequelize = new Sequelize('db', 'user', 'pass', { dialect: 'mysql', replication: { read: [{ host: 'slave1', username: 'user', password: 'pass' }], write: { host: 'master', username: 'user', password: 'pass' } } });分区表改造
按时间范围拆分订单表：ALTER TABLE `order` PARTITION BY RANGE (YEAR(created_at)) ( PARTITION p2021 VALUES LESS THAN (2022), PARTITION p2022 VALUES LESS THAN (2023), PARTITION pMax VALUES LESS THAN MAXVALUE );
SQL重写：确保查询时间范围在单个分区：
WHERE created_at >= '2023-01-01' AND created_at < '2023-07-01'
效果：主库负载下降60%，读接口响应时间稳定在200毫秒以内。
五、慢查询日志管理最佳实践
日志轮转与清理
使用
logrotate工具定期切割日志，避免磁盘空间耗尽。示例配置：
/var/log/mysql/mysql-slow.log { daily rotate 7 compress missingok notifempty create 640 mysql mysql }生产环境建议
避免长期开启
log_queries_not_using_indexes，防止日志量过大。结合监控系统（如Prometheus+Grafana）实时报警慢查询突增。
索引优化原则
对高频出现在
WHERE、JOIN、ORDER BY的字段添加索引。避免过度索引：每个额外索引会降低10%的写入性能。
六、总结
MySQL慢查询日志是性能优化的“黑匣子”，通过合理配置日志参数、选择分析工具（如mysqldumpslow、pt-query-digest），并结合EXPLAIN执行计划分析，可系统性解决数据库性能瓶颈。实际优化中需结合业务场景，灵活运用索引优化、SQL重写、读写分离等技术手段，持续监控并迭代优化方案。
本文由@战地网 原创发布。
该文章观点仅代表作者本人，不代表本站立场。本站不承担相关法律责任。
如若转载，请注明出处：https://www.zhanid.com/biancheng/4927.html
