SQL查询慢是数据库应用中常见的性能问题，会直接影响业务系统的响应速度和用户体验，掌握完整的慢SQL排查流程能快速定位问题根源并针对性优化。
开启慢查询日志
慢查询日志是数据库自动记录执行时间超过指定阈值的SQL语句的功能，是定位慢SQL最直接的方式。不同数据库的开启方式略有差异，以MySQL为例，可以通过配置文件或命令行临时开启。
首先查看当前慢查询日志的配置状态：
-- 查看慢查询日志是否开启 SHOW VARIABLES LIKE 'slow_query_log'; -- 查看慢查询的时间阈值，单位秒 SHOW VARIABLES LIKE 'long_query_time'; -- 查看慢查询日志的存储路径 SHOW VARIABLES LIKE 'slow_query_log_file';
如果需要临时开启慢查询日志并设置阈值为1秒，可以执行以下命令：
-- 开启慢查询日志 SET GLOBAL slow_query_log = 'ON'; -- 设置慢查询阈值为1秒，执行时间超过1秒的SQL会被记录 SET GLOBAL long_query_time = 1; -- 记录未使用索引的查询 SET GLOBAL log_queries_not_using_indexes = 'ON';
永久开启需要修改MySQL的配置文件my.cnf，在[mysqld]段添加以下配置后重启服务：
[mysqld] slow_query_log = 1 slow_query_log_file = /var/lib/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1
分析慢查询日志内容
慢查询日志中会记录每条慢SQL的执行时间、锁定时间、返回行数、执行的SQL语句等信息，直接查看日志文件内容即可获取相关信息：
# Time: 2024-05-20T10:30:15.123456Z # User@Host: root[root] @ localhost [] Id: 123 # Query_time: 2.345 Lock_time: 0.012 Rows_sent: 100 Rows_examined: 100000 SET timestamp=1716197415; SELECT * FROM order_info WHERE user_id = 100 AND status = 2;
上述日志中，Query_time是SQL的总执行时间，Lock_time是表锁占用的时间，Rows_examined是查询扫描的行数，Rows_sent是返回给客户端的行数。如果Rows_examined远大于Rows_sent，说明SQL可能缺少合适的索引，扫描了大量无效数据。
如果日志内容较多，可以使用mysqldumpslow工具进行汇总分析，快速找到出现频率最高的慢SQL：
# 统计慢查询日志中出现次数最多的10条SQL mysqldumpslow -s c -t 10 /var/lib/mysql/slow.log # 按照查询时间排序，展示最慢的5条SQL mysqldumpslow -s t -t 5 /var/lib/mysql/slow.log
使用explain查看执行计划
定位到具体的慢SQL后，需要使用explain命令查看SQL的执行计划，分析数据库是如何执行这条SQL的，从而找到性能瓶颈。在SQL语句前加上EXPLAIN关键字即可查看执行计划。
-- 查看慢SQL的执行计划 EXPLAIN SELECT * FROM order_info WHERE user_id = 100 AND status = 2;
执行后会返回如下表格信息：
| 字段名 | 含义说明 |
|---|---|
| id | 查询的序列号，表示查询的执行顺序 |
| select_type | 查询类型，比如SIMPLE表示简单查询，SUBQUERY表示子查询 |
| table | 当前查询涉及的表名 |
| type | 访问类型，性能从优到差依次为system>const>eq_ref>ref>range>index>ALL |
| possible_keys | 可能使用的索引列表 |
| key | 实际使用的索引，如果为NULL表示未使用索引 |
| rows | 预估需要扫描的行数，数值越小越好 |
| Extra | 额外信息，比如Using filesort表示需要额外排序，Using temporary表示使用临时表 |
如果type为ALL，说明进行了全表扫描，需要检查是否有合适的索引；如果Extra出现Using filesort或Using temporary，说明查询过程中进行了额外的排序或临时表操作，也需要优化。
检查索引使用情况
索引缺失或使用不当是SQL查询慢的常见原因，需要检查慢SQL涉及的字段是否有合适的索引。首先查看表的索引结构：
-- 查看order_info表的索引信息 SHOW INDEX FROM order_info;
如果user_id和status字段没有联合索引，可以创建联合索引提升查询效率：
-- 创建user_id和status的联合索引 CREATE INDEX idx_user_status ON order_info(user_id, status);
需要注意索引的创建原则，避免在低区分度的字段上创建索引，同时不要创建过多冗余索引，否则会影响写入性能。如果已经存在索引但SQL没有使用，可能是索引字段参与了函数运算、类型转换，或者查询条件不符合最左前缀原则。
其他排查方向
除了索引问题，还可以排查以下场景：
- SQL语句本身是否存在问题，比如是否查询了不必要的字段，是否可以使用连接查询代替子查询，是否存在不必要的排序或分组操作
- 数据库服务器的资源使用情况，比如CPU、内存、磁盘IO是否达到瓶颈，是否存在锁等待、死锁问题
- 表的数据量是否过大，是否需要分库分表，或者是否需要清理历史无用数据
- 数据库的配置参数是否合理，比如缓冲池大小、连接数配置是否符合当前业务负载
可以通过以下命令查看当前数据库的锁等待情况：
-- 查看InnoDB引擎的锁等待信息 SELECT * FROM information_schema.INNODB_LOCKS; SELECT * FROM information_schema.INNODB_LOCK_WAITS;
慢SQL优化示例
假设定位到如下慢SQL，执行时间超过2秒，扫描行数10万行：
SELECT * FROM order_info WHERE create_time > '2024-01-01' AND status = 1 ORDER BY update_time DESC LIMIT 20;
通过explain分析发现type为ALL，未使用索引，Extra出现Using filesort。优化方案如下：
- 创建
status、create_time、update_time的联合索引，覆盖查询条件和排序字段 - 只查询需要的字段，避免
SELECT *
优化后的SQL如下：
-- 优化后的SQL，只查询需要的字段 SELECT order_id,user_id,status,create_time,update_time FROM order_info WHERE create_time > '2024-01-01' AND status = 1 ORDER BY update_time DESC LIMIT 20;
同时创建对应的联合索引：
CREATE INDEX idx_status_create_update ON order_info(status, create_time, update_time);
优化后再次执行explain，可以看到type变为range，key使用了新创建的索引，rows扫描行数降低到几百行，Extra中不再出现Using filesort，查询时间缩短到几十毫秒。
慢SQLSQL查询优化数据库性能分析explain执行计划修改时间：2026-06-26 09:24:37