答案是定位耗时操作并分析执行路径。通过开启慢查询日志筛选慢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';重点关注以下字段：
- 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，是标准流程。关键是养成习惯，定期巡检慢查询日志。
