树叶云数据库里教你怎么看MySQL慢查询日志，搞懂Slow Query Log的那些事儿

根据“树叶云数据库”的分享，看懂MySQL的慢查询日志（Slow Query Log）就像是给数据库做了一次“体检”，它能告诉你哪些SQL语句“生病”了——也就是执行得太慢了，拖累了整个数据库的性能，这篇文章的目的就是帮你搞懂这份“体检报告”里的每一项指标是什么意思，以及你该如何着手去“治疗”。

第一部分：什么是慢查询日志？为什么要开启它？

慢查询日志是MySQL提供的一个功能，它会自动把所有执行时间超过某个设定值（比如1秒）的SQL语句记录下来，写入一个文件里，这个功能默认是关闭的，因为记录日志本身也会消耗一点点性能，但对于需要优化数据库的开发者或运维人员来说,它是必不可少的利器。

“树叶云数据库”打了个比方：如果你的网站或应用突然变慢了，你感觉是数据库的问题，但又不知道具体是哪里出了问题，慢查询日志就像是一个监控摄像头，它能精准地抓到那个“肇事”的慢SQL，没有它，你就像在黑暗中摸索，只能靠猜；有了它,你就能直接看到问题所在。

第二部分：如何开启和设置慢查询日志？

在开始分析之前，你得先确保慢查询日志已经打开了，你可以通过MySQL的命令行客户端连接到你的数据库，然后执行一些命令来查看和设置相关参数,主要关注以下几个关键设置：

1. slow_query_log：这个参数控制慢查询日志的开关，把它设置为ON,就表示开启日志功能。
2. long_query_time：这是最重要的一个参数，它定义了“慢”的标准，单位是秒，默认是10秒，也就是说，执行时间超过10秒的SQL才会被记录，但在实际生产环境中，这个值通常设得更小，比如1秒甚至0.1秒,因为一个良好的应用不应该有这么多长时间运行的查询。
3. slow_query_log_file：这个参数指定了慢查询日志文件存放在服务器的哪个位置，你需要知道这个路径,才能找到并查看日志文件。
4. log_queries_not_using_indexes：如果把这个参数设置为ON，那么即使某些SQL执行得很快，但只要它没有使用索引，也会被记录到慢查询日志里，这对于发现潜在的性能问题非常有用,因为全表扫描的查询在数据量增大后很容易变慢。

你可以在MySQL中执行 SHOW VARIABLES LIKE 'slow_query%'; 和 SHOW VARIABLES LIKE 'long_query_time'; 来查看当前的设置情况。

第三部分：慢查询日志里到底写了什么？一行记录怎么看懂？

开启日志后，MySQL就会在指定的文件里记录慢SQL，每一条记录都包含了丰富的信息，“树叶云数据库”详细解释了其中几个关键字段的含义,我们来看一个典型的例子：

# Time: 2023-10-27T08:45:12.123456Z
# User@Host: db_user[db_user] @  [192.168.1.100]  Id:   123
# Query_time: 3.456789  Lock_time: 0.001234 Rows_sent: 1  Rows_examined: 1000000
SET timestamp=1698391512;
SELECT * FROM order_history WHERE user_id = 12345 AND product_name LIKE '%折扣%';

我们来逐一拆解：

• Time：SQL语句执行完成的准确时间点,这对于排查在特定时间段发生的性能问题很有帮助。
• User@Host：是哪个用户从哪个IP地址执行了这条SQL,这可以帮助你判断是哪个应用或者哪个环节发出的请求。
• Query_time：这是最核心的指标，表示这个SQL语句执行了多长时间，例子中用了3.45秒,这显然太慢了。
• Lock_time：表示这条SQL等待锁的时间（比如等待其他事务释放行锁或表锁），如果这个时间很长,说明可能存在锁竞争。
• Rows_sent：服务器返回给客户端的数据行数,例子中只返回了1行。
• Rows_examined：服务器为了执行这条查询，实际扫描了多少行数据，例子中扫描了100万行！这是一个非常危险的信号。

“树叶云数据库”特别强调，要重点关注 Rows_examined 和 Rows_sent 的比值，在这个例子里，扫描了100万行才返回1行数据，效率极低，这通常意味着查询没有使用到合适的索引,导致了全表扫描。

• 最后一行就是完整的SQL语句本身，这是你分析问题的根本,你需要仔细看这个SQL是在查什么。

第四部分：拿到慢查询日志后，我们该怎么做？

“树叶云数据库”指出，分析日志的最终目的是为了解决问题，当你找到一条慢SQL后,通常可以从以下几个方面入手：

1. 检查是否缺少索引：这是最常见的原因，比如上面的例子，在user_id和product_name字段上增加合适的索引，可能会让查询速度提升成千上万倍，可以使用EXPLAIN命令来查看SQL的执行计划,确认它是否使用了索引。
2. 优化SQL语句本身：有时候SQL写得不好也会导致性能低下，比如使用了SELECT *（只查询需要的列）、不必要的子查询、或者LIKE ‘%前缀%’这种无法使用索引的模糊查询，尝试重写SQL,用更高效的方式实现同样的功能。
3. 分析业务逻辑：是不是一次请求查询了太多不需要的数据？能不能分页查询？是不是可以增加缓存，避免频繁查询数据库？这些是从应用层面优化的思路。

总结一下

“树叶云数据库”的这份指南核心思想就是：慢查询日志是数据库性能优化的“入口”，你不需要一开始就精通所有数据库内核原理，但一定要学会使用这个工具，它的步骤很清晰：先打开日志功能，设置合理的阈值；然后学会解读日志中的关键数字，特别是执行时间和扫描行数；最后针对找到的慢SQL，从索引、SQL写法、业务逻辑三个方向去尝试优化，通过不断重复这个过程,你就能逐步提升数据库的整体性能。