怎么实例详解mysql记录耗时的sql语句

在MySQL数据库的日常运维和开发过程中，执行耗时的SQL语句往往是导致系统性能下降的核心原因，记录这些慢SQL是性能优化的第一步。通过开启慢查询日志功能，我们可以自动捕获所有执行时间超过指定阈值的SQL语句，为后续的优化工作提供明确的方向。

开启MySQL慢查询日志的基础配置

MySQL本身内置了慢查询日志功能，默认情况下该功能可能是关闭状态，我们需要先修改对应的配置参数来开启它。首先可以通过SQL命令查看当前慢查询相关的配置状态：

-- 查看慢查询日志是否开启
SHOW VARIABLES LIKE 'slow_query_log';
-- 查看慢查询的时间阈值，单位秒
SHOW VARIABLES LIKE 'long_query_time';
-- 查看慢查询日志的存储路径
SHOW VARIABLES LIKE 'slow_query_log_file';

如果需要临时开启慢查询日志，可以执行以下命令，不过这种配置在MySQL重启后会失效：

-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
-- 设置耗时阈值为2秒，执行超过2秒的SQL会被记录
SET GLOBAL long_query_time = 2;
-- 设置慢查询日志的存储文件，路径可以根据实际情况调整
SET GLOBAL slow_query_log_file = '/var/lib/mysql/slow-query.log';

永久配置慢查询日志

如果希望MySQL重启后慢查询配置依然生效，需要修改MySQL的配置文件，Linux系统下通常是my.cnf，Windows系统下是my.ini，在[mysqld]配置段添加以下内容：

[mysqld]
# 开启慢查询日志
slow_query_log = ON
# 慢查询时间阈值，单位秒，这里设置为1秒
long_query_time = 1
# 慢查询日志存储路径
slow_query_log_file = /var/lib/mysql/slow-query.log
# 记录未使用索引的查询，即使执行时间未超过阈值也会被记录
log_queries_not_using_indexes = ON

修改完成后重启MySQL服务，配置即可生效。添加log_queries_not_using_indexes参数后，即使SQL执行时间没有超过long_query_time的阈值，只要没有使用索引也会被记录到慢查询日志中，方便我们提前发现潜在的索引问题。

慢查询日志的内容解析

当慢查询日志开启后，执行一条耗时超过阈值的SQL，日志文件中会记录对应的详细信息，以下是一个典型的慢查询日志记录示例：

# Time: 2024-05-20T10:30:15.123456Z
# User@Host: root[root] @ localhost []  Id: 123
# Query_time: 3.234567  Lock_time: 0.001234  Rows_sent: 10  Rows_examined: 100000
SET timestamp=1716196215;
SELECT * FROM user_table WHERE age > 18 ORDER BY create_time DESC LIMIT 10;

这段日志中各个字段的含义如下：

• Time：SQL语句执行的时间点
• User@Host：执行SQL的用户和客户端主机信息
• Query_time：SQL语句的执行总耗时，单位是秒
• Lock_time：SQL执行过程中等待锁的耗时
• Rows_sent：返回给客户端的行数
• Rows_examined：执行过程中扫描的行数，这个数值越大通常说明SQL效率越低
• 最后一行就是实际执行的慢SQL语句

慢查询日志的分析工具使用

如果慢查询日志中的记录很多，手动逐行查看效率很低，MySQL官方提供了mysqldumpslow工具来快速分析慢查询日志，以下是常用的命令示例：

# 查看慢查询日志中耗时最长的10条SQL
mysqldumpslow -s t -t 10 /var/lib/mysql/slow-query.log
# 查看访问次数最多的10条慢SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/slow-query.log
# 按照锁时间排序，查看锁等待最严重的10条SQL
mysqldumpslow -s l -t 10 /var/lib/mysql/slow-query.log

mysqldumpslow的-s参数用于指定排序规则，可选值有t（查询时间）、c（访问次数）、l（锁时间）、r（返回行数），-t参数用于指定输出的记录条数。

实际实例演示

我们创建一个测试表，插入10万条测试数据，然后执行一条没有使用索引的查询，观察慢查询日志的记录情况：

-- 创建测试表
CREATE TABLE test_slow (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50),
    age INT,
    create_time DATETIME
);
-- 插入10万条测试数据，这里用存储过程实现
DELIMITER //
CREATE PROCEDURE insert_test_data()
BEGIN
    DECLARE i INT DEFAULT 0;
    WHILE i < 100000 DO
        INSERT INTO test_slow (name, age, create_time) 
        VALUES (CONCAT('user_', i), FLOOR(RAND() * 100), NOW());
        SET i = i + 1;
    END WHILE;
END //
DELIMITER ;
-- 执行存储过程插入数据
CALL insert_test_data();
-- 执行一条没有索引的查询，age字段没有建索引，扫描全表
SELECT * FROM test_slow WHERE age = 50 LIMIT 10;

如果long_query_time设置为1秒，这条查询扫描了10万行数据，执行时间大概率会超过阈值，此时查看慢查询日志就能找到这条SQL的记录，之后我们可以给age字段添加索引来优化这条SQL：

-- 给age字段添加索引
ALTER TABLE test_slow ADD INDEX idx_age (age);
-- 再次执行相同的查询，执行时间会大幅降低，不再被记录到慢查询日志中
SELECT * FROM test_slow WHERE age = 50 LIMIT 10;

注意事项

开启慢查询日志会对MySQL的性能有轻微的影响，因为需要额外的IO操作来写入日志，所以在生产环境中建议根据实际需求调整long_query_time的阈值，不要设置得过小，避免记录过多无用的SQL。另外慢查询日志文件会不断增大，需要定期清理或者归档，避免占用过多的磁盘空间。

MySQLslow_query_logSQL_优化long_query_time日志分析修改时间：2026-06-29 11:00:34