当前位置：首页 > news >正文

简易分析慢 SQL 的流程和方法

news 2025/9/29 6:22:50

分析慢 SQL 的核心是定位性能瓶颈（如全表扫描、索引失效、锁等待等），并针对性优化。以下是一套标准化的分析流程，从日志获取到根因定位，再到优化验证：

一、第一步：获取慢 SQL（开启并查看慢查询日志）

首先确保慢查询日志已开启，才能捕获到慢 SQL。

检查 / 开启慢查询日志登录 MySQL 执行命令，查看当前配置：

-- 查看是否开启（ON为开启，OFF为关闭）
SHOW VARIABLES LIKE 'slow_query_log';
-- 查看慢查询阈值（单位：秒，默认10秒，可根据业务调整为1秒）
SHOW VARIABLES LIKE 'long_query_time';
-- 临时开启（重启MySQL后失效，生产环境需在my.cnf中配置永久生效）
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; -- 阈值设为1秒，捕获更精细的慢SQL

查看慢查询日志内容先找到日志路径：

SHOW VARIABLES LIKE 'slow_query_log_file';

再通过服务器命令查看日志（如 Linux）：

# 直接查看最新日志
cat /var/lib/mysql/xxx-slow.log
# 或用MySQL自带工具mysqldumpslow分析（按执行次数排序，取前10条）
mysqldumpslow -s c -t 10 /var/lib/mysql/xxx-slow.log

二、第二步：用`EXPLAIN`分析 SQL 执行计划（核心步骤）

拿到慢 SQL 后，最关键的是通过EXPLAIN查看 MySQL 的 “执行思路”，定位瓶颈。

1. 基本用法

在慢 SQL 前加EXPLAIN，例如：

EXPLAIN SELECT * FROM user WHERE age > 30 AND name LIKE '%张三%';

执行后会输出 12 列关键信息，重点关注以下 6 列：

列名	核心含义	异常信号（需优化）
id	SQL 执行顺序（数字越大越先执行，相同则按从上到下顺序）	无异常，但需理解多表关联时的执行逻辑
select_type	查询类型（如 SIMPLE = 简单查询、SUBQUERY = 子查询、JOIN = 关联查询）	出现`ALL`（全表扫描）、`filesort`（文件排序）、`using temporary`（临时表）
table	当前行正在访问的表	无直接异常，但需结合其他列判断
type	表的访问方式（性能从好到差：`system` > `const` > `eq_ref` > `ref` > `range` > `index` > `ALL`）	出现`ALL`（全表扫描，数据量大时必慢）、`index`（全索引扫描）
key	实际使用的索引（`NULL`表示未使用索引）	为`NULL`且`type`是`ALL`（未走索引）
Extra	额外执行信息（最能暴露问题的列）	包含`Using filesort`（需优化排序）、`Using temporary`（需优化临时表）、`Using where`（过滤在内存完成，无大问题）

2. 常见`EXPLAIN`异常及原因

异常 1：type=ALL（全表扫描）原因：未建索引、索引失效（如LIKE '%xx'、函数操作索引列、类型不匹配）。
异常 2：Extra=Using filesort原因：排序字段未走索引，MySQL 需在内存 / 磁盘中手动排序（数据量大时极慢）。
异常 3：Extra=Using temporary原因：需创建临时表存储中间结果（如GROUP BY未走索引、多表关联排序未优化）。

三、第三步：补充分析工具（深入定位细节）

除了EXPLAIN，还可结合以下工具获取更具体的性能数据：

EXPLAIN ANALYZE（MySQL 8.0.18 + 支持）比EXPLAIN更精准，会实际执行 SQL并返回真实的执行时间、行数等（注意：生产环境执行前需评估 SQL 是否会锁表或消耗资源）：
sql
```
EXPLAIN ANALYZE SELECT * FROM user WHERE age > 30;
```
查看 SQL 执行时间和锁等待通过SHOW PROFILE查看 SQL 执行的每个阶段耗时（需先开启）：
sql
```
-- 开启 profiling
SET profiling = ON;
-- 执行慢SQL
SELECT * FROM user WHERE age > 30;
-- 查看最近一次SQL的执行详情
SHOW PROFILE FOR QUERY 1; -- 1是SQL的ID，可通过SHOW PROFILES查看
```
若耗时集中在Sending data（数据传输）或Waiting for table level lock（表锁等待），需进一步优化数据量或锁策略。

四、第四步：常见慢 SQL 根因及优化方向

根据上述分析，定位根因后针对性优化：

常见根因	优化方案
1. 未建索引 / 索引失效	- 给过滤条件（`WHERE`）、排序（`ORDER BY`）、关联（`JOIN ON`）字段建索引- 避免索引失效：不用`LIKE '%xx'`（改用`LIKE 'xx%'`）、不函数操作索引列（如`DATE(created_at) = '2024-01-01'`改为`created_at BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59'`）
2. 全表扫描（数据量大）	- 建合适索引- 分表分库（如按时间分表、按用户 ID 分库）- 避免`SELECT *`，只查需要的字段（减少数据传输和内存消耗）
3. 排序 / 分组未走索引	- 给`ORDER BY/GROUP BY`的字段建联合索引（如`WHERE age >30 ORDER BY create_time`，建索引`(age, create_time)`）- 减少排序数据量（先过滤再排序）
4. 多表关联效率低	- 确保关联字段（`JOIN ON`）有索引- 小表驱动大表（如`SELECT * FROM 小表 JOIN 大表 ON ...`）- 避免`LEFT JOIN`时右边表的过滤条件写在`WHERE`中（会导致`LEFT JOIN`变`INNER JOIN`）
5. 事务 / 锁等待	- 缩短事务时长（避免在事务中执行非数据库操作，如 RPC 调用）- 用行锁（`InnoDB`）替代表锁，避免长事务占用锁资源