我们经常遇到数据库性能瓶颈，尤其是当 SQL 执行时间过长时，排查起来非常头疼。今天就来聊聊如何通过 MySQL 的慢查询日志和 mysqldumpslow 工具，快速定位那些“拖后腿”的 SQL 语句。

启用慢查询日志是分析数据库性能的第一步，它能记录所有执行时间超过设定阈值的 SQL 语句。而 mysqldumpslow 是 MySQL 自带的一个工具，专门用来解析这些日志文件，帮助我们高效地找出最耗时的查询。

首先，我们需要在 MySQL 配置文件中开启慢查询日志。通常这个文件是 /etc/my.cnf 或 /etc/mysql/my.cnf，具体路径可能因系统而异。我们可以添加以下几行：

这段配置的作用是：

slow_query_log = 1：开启慢查询日志。

slow_query_log_file：指定日志保存的位置，这里我选的是 /var/log/mysql/slow.log。

long_query_time = 2：设置慢查询的阈值为 2 秒，超过这个时间的 SQL 就会被记录下来。

注意：如果你使用的是 MySQL 8.0 及以上版本，slow_query_log_file 可能需要配合 log_output 参数一起使用，比如设置 log_output = FILE 来确保日志写入到文件中。

配置完成后，重启 MySQL 服务让设置生效。在 Linux 系统中，可以使用如下命令：

或者根据你的系统使用 service mysql restart。

接下来，我们要用 mysqldumpslow 来分析日志文件。假设我们的慢查询日志文件是 /var/log/mysql/slow.log，那么运行下面的命令就能看到按执行时间排序的 SQL 列表：

这里的 -s t 表示按照执行时间（time）排序，你也可以用 -s l 按锁时间排序，或者 -s c 按出现次数排序。

mysqldumpslow 输出的结果会显示每个 SQL 的执行次数、总时间、平均时间等信息，比如：

这说明这条 SQL 执行了 5 次，总共耗时 15.6 秒，平均每次 3.12 秒，返回了 500 行数据。

但有时候你会发现，日志文件太大，直接看太麻烦。这时候可以用一些更高级的参数来筛选或格式化输出。比如只看执行时间最长的 10 条：

或者只看某个特定用户的查询：

除了 mysqldumpslow，你还可以结合 grep 或 awk 等工具进一步处理日志内容。例如，查找包含 WHERE id = 的慢查询：

不过这种方式比较原始，建议还是优先使用 mysqldumpslow，因为它对日志格式有专门的解析逻辑。

在实际使用中，有几个小坑需要注意：

1. 权限问题：mysqldumpslow 通常需要访问 MySQL 的日志文件，如果权限不足，可能会报错。你可以用 sudo 提权运行，或者调整日志文件的权限。

2. 日志文件过大：如果慢查询日志很大，mysqldumpslow 可能会运行较慢。建议定期清理或分割日志文件。

3. 日志未正确生成：如果开启了慢查询日志但没有看到任何记录，可能是配置错误，或者查询时间太短没达到 long_query_time 的阈值。

总的来说，掌握慢查询日志和 mysqldumpslow 是优化 MySQL 性能的关键一步。它们能帮助你快速发现数据库中的“罪魁祸首”，从而有针对性地进行索引优化、SQL 重写等操作。

今天我们介绍了如何开启慢查询日志，以及如何使用 mysqldumpslow 分析这些日志，找出执行时间长的 SQL。掌握了这些技巧，你就能更高效地排查数据库性能问题，提升应用响应速度。

如果你也喜欢这类实用的数据库优化技巧，欢迎关注我，我会持续分享更多数据库自动化和性能调优的内容。更多实战经验，记得点赞+收藏不迷路！

#优质图文扶持计划#