MySQL慢日志分析优化数据库实战教程：从开启到调优

为什么要关注MySQL慢日志？

MySQL慢日志是记录执行时间超过阈值SQL的日志文件，是数据库性能优化的第一手资料。
当网站变慢、接口超时，先查慢日志往往能快速定位罪魁祸首。
即使是零基础用户，只需要简单几个命令就能打开这把“性能钥匙”。

三步开启慢查询日志

1. 检查当前状态

登录MySQL，先看慢日志是否开启：

SHOW VARIABLES LIKE 'slow_query_log%';

如果 slow_query_log 为 OFF，继续下一步。

2. 动态开启（无需重启）

执行以下SQL（重启后失效，永久开启见下文）：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;   -- 超过2秒的记录
SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';

其中 long_query_time 可以根据业务调整，通常从2秒开始。

3. 永久开启

编辑MySQL配置文件（通常为 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），在 [mysqld] 段添加：

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes = 1

然后重启MySQL：systemctl restart mysql。

用mysqldumpslow快速分析日志

慢日志直接打开可能很乱。
Linux自带的 mysqldumpslow 工具可以汇总统计：

mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log

• -s t 按查询时间排序
• -t 10 只显示前10条

结果会显示最慢的那些SQL以及执行次数和平均耗时。
如果你习惯图形界面，也可以把日志下载到本地用 pt-query-digest 或宝塔面板的日志分析功能。

常见慢查询场景与优化

全表扫描

症状：type: ALL 出现在 EXPLAIN 输出中。
优化：给 WHERE 条件中的字段加索引。比如 SELECT * FROM orders WHERE status = 1，就在 status 上加普通索引。

排序或分组导致临时文件

症状：Using filesort 或 Using temporary。
优化：确保 ORDER BY 和 GROUP BY 的字段包含在联合索引中，或者只选择必要字段，避免 SELECT *。

数据量过大

症状：单表数据超过千万行。
优化：考虑分区表或分库分表，同时定期归档历史数据。

避坑与验证优化效果

• 坑1：慢日志文件会越来越大，生产环境需定期轮转。可以用 mysqladmin flush-logs 或 crontab 脚本自动切割。
• 坑2：long_query_time 设置过小（如0.1秒）会记录大量正常SQL，影响性能。建议从2秒开始，逐步调低。
• 坑3：修改慢日志配置后，记得用 SHOW VARIABLES 确认生效，部分环境需要重启。

验证方法：优化后再次用 mysqldumpslow 对比排名靠前的SQL是否消失，同时观察业务接口响应时间。
你也可以在应用中埋点测试慢查询前后的耗时变化。

总结

掌握 MySQL慢日志分析优化数据库 的核心思路：开启日志 → 分析定位 → 加索引/改SQL → 验证效果。
这套流程适合所有MySQL版本，新手只要跟着命令做就能快速上手。
下次遇到数据库性能问题，别急着重启，先慢日志走一遍。