答案是定位耗时操作并分析执行路径。通过开启慢查询日志筛选慢sql，使用EXPLaiN查看执行计划，重点检查type、key、rows和Extra字段，排查缺失索引、索引失效、扫描过多、回表严重等问题，结合performance_schema统计进一步诊断，最终优化SQL和索引设计。

分析 mysql 慢查询的根本原因，关键在于定位耗时操作并理解其执行路径。核心方法是开启慢查询日志，结合 EXPLAIN 分析执行计划，再从索引、表结构、SQL 写法等角度排查。

1. 开启并查看慢查询日志

确保 MySQL 已记录执行时间较长的 SQL，这是分析的前提。

— 查看慢查询日志是否开启
SHOW VARIABLES LIKE ‘slow_query_log’;
— 查看慢查询阈值（单位：秒）
SHOW VARIABLES LIKE ‘long_query_time’;
— 临时开启慢查询日志（需有权限）
SET GLOBAL slow_query_log = ‘ON’;
SET GLOBAL long_query_time = 1;

日志文件中会记录超过阈值的 SQL 及其执行时间、锁等待时间等信息，可用于筛选重点优化对象。

2. 使用 EXPLAIN 分析执行计划

对慢查询语句前加上 EXPLAIN，查看 MySQL 如何执行这条 SQL。

EXPLAIN select * FROM users WHERE name = ‘John’;

重点关注以下字段：

因赛AIGC

因赛AIGC解决营销全链路应用场景

73

查看详情

• type：访问类型，ALL 表示全表扫描，性能最差；index 或 ref 更好
• key：实际使用的索引，为 NULL 说明未走索引
• rows：扫描行数，越大越慢
• Extra：额外信息，出现 using filesort 或 Using temporary 通常表示性能问题

3. 常见慢查询原因及对策

根据 EXPLAIN 结果和业务逻辑，排查以下常见问题：

• 缺少有效索引：WHERE、JOIN、ORDER BY 字段未建索引。解决方法是创建合适的单列或复合索引
• 索引失效：使用函数、类型转换、% 前缀模糊匹配（LIKE ‘%abc’）会导致索引无法使用
• 扫描行数过多：即使有索引，若过滤性差（如查性别字段），MySQL 可能选择全表扫描
• 回表严重：覆盖索引可减少回表，SELECT 尽量避免用 *
• 数据量过大：考虑分库分表或归档历史数据
• 锁竞争：长时间运行的事务阻塞其他操作，可通过 SHOW ENGINE INNODB STATUS 查看锁情况

4. 利用 performance_schema 进一步诊断

MySQL 自带的 performance_schema 提供更细粒度的运行时统计。

SELECT * FROM performance_schema.events_statements_history WHERE sql_text LIKE ‘%users%’;

可查看 SQL 的执行次数、平均耗时、锁时间、IO 次数等，帮助识别高频慢语句。

基本上就这些。开启日志、看执行计划、查索引、优化 SQL，是标准流程。关键是养成习惯，定期巡检慢查询日志。