MySQL 慢查询日志开启、解析与性能优化实战

理解慢查询日志结构与前提条件

MySQL 默认的慢日志通常保存在文件中。一条标准的慢查询日志记录包含以下关键信息：

• Time: 时间戳
• User@Host: 执行该语句的用户和连接来源
• Query_time: 查询执行花费的时间
• Lock_time: 等待锁的时间
• Rows_sent / Rows_examined: 发送的行数与扫描的行数

若要查看以表格存储（mysql.slow_log）时的详细字段定义，可执行：

SHOW CREATE TABLE mysql.slow_log;

第一步：查看当前慢查询参数状态

进入 MySQL 终端，通过以下变量了解当前的记录开关与路径：

SHOW VARIABLES LIKE '%slow_query%';

重点关注 slow_query_log（是否开启）与 slow_query_log_file（文件路径）。决定记录内容的几个核心参数包括：

• 不使用索引的记录开关：
  

  SHOW GLOBAL VARIABLES LIKE '%indexes%';

  其中 log_queries_not_using_indexes=OFF 表示不强制记录全表扫描或无索引查询；log_throttle_queries_not_using_indexes 用于限制每分钟记录的次数。
• 长时间查询阈值：
  

  SHOW GLOBAL VARIABLES LIKE '%long_query%';

  long_query_time 设定了判断“慢”的时间界限，默认通常为 10 秒。
• 最小扫描行数阈值：
  

  SHOW VARIABLES LIKE '%min_examined_row_limit%';

  默认为 0，代表不论扫描多少行均按时间判断。

第二步：开启慢日志并调整记录策略

在 MySQL 会话中直接修改全局参数（重启后失效）或在配置文件中添加启动参数：

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.1; -- 设置为0.1秒捕获更多潜在问题
SET GLOBAL log_queries_not_using_indexes = ON;

在生产环境中开启无索引查询记录需谨慎，这可能导致日志量激增影响系统性能，建议同时关注流量控制参数。

第三步：使用分析工具提取高危 SQL

当慢日志体积庞大且存在大量重复时，手动阅读效率极低。推荐使用官方附带的 Perl 脚本 mysqldumpslow 进行聚合统计：

./mysqldumpslow -s t -t 10 /usr/local/mysql/data/cloudlu-slow.log

常用参数说明：

• -s t: 按照总耗时排序 (time)
• -c: 按照次数排序 (count)
• -t n: 显示前 N 条最典型的慢查询

进阶替代方案：
对于更细致的分析报告（如计算平均耗时、95%分位值、锁等待占比），可使用 mysqlsla 或 pt-query-digest（Percona Toolkit 组件），它们能提供更直观的统计数据。

第四步：执行计划分析与优化验证

通过上述工具筛选出 Top N 慢 SQL 后，需在数据库中逐一排查。使用 EXPLAIN 或 DESC 查看具体语句的执行过程：

EXPLAIN SELECT * FROM test.t;

分析输出结果时需重点核对以下几点：

1. type: 是否为 ALL（全表扫描），这是性能最差的情形。
2. key: 实际使用的索引列。若为 NULL 则说明未走索引。
3. Extra: 避免出现 Using filesort 或 Using temporary，这通常意味着需要对数据进行额外排序或生成临时表。

总结与风险提示

SQL 优化是一个权衡的过程。引入索引虽然能大幅提升读取速度（降低 type 等级），但会增加存储空间并在写入（INSERT/UPDATE/DELETE）时增加开销。在写入密集型系统中，盲目增加索引可能导致写入延迟飙升。因此，优化后务必持续监控系统负载，确保引入了新的性能瓶颈。

以上就是 MySQL 慢查询日志分析与优化的详细内容，更多关于 SQL 性能调优的资料请关注本站其它相关文章！