通过EXPLaiN分析执行计划可定位sql性能瓶颈，重点关注type（避免ALL全表扫描）、rows（扫描行数越少越好）和Extra（警惕using filesort和Using temporary），结合EXPLAIN format=jsON获取查询成本、排序方式等详细信息，并配合慢查询日志与pt-query-digest工具识别高耗时SQL，及时优化索引设计与SQL写法以提升执行效率。

在 mysql 中分析执行计划，是定位 SQL 性能瓶颈的关键步骤。通过 EXPLAIN 或 EXPLAIN FORMAT=json 命令可以查看查询的执行方式，进而发现潜在问题。以下是具体方法和常见性能瓶颈的识别方式。

使用 EXPLAIN 查看执行计划

在 SQL 语句前加上 EXPLAIN，即可查看 MySQL 如何执行该查询：

EXPLAIN select * FROM users WHERE age > 30;

输出结果包含以下关键字段：

• id：查询序列号，越大优先级越高，相同则按顺序执行
• select_type：查询类型（如 SIMPLE、PRIMARY、SUBQUERY）
• table：涉及的表名
• type：连接类型，反映访问方式效率
• possible_keys：可能使用的索引
• key：实际使用的索引
• key_len：使用的索引长度，越短越好
• ref：显示哪些列或常量被用于索引查找
• rows：估算需要扫描的行数，值越大性能越差
• Extra：额外信息，非常重要

重点关注的性能信号

通过观察 EXPLAIN 输出中的关键字段，可以快速识别性能问题：

1. type 字段值较差

• 理想情况是 const、eq_ref、ref
• 出现 ALL 表示全表扫描，通常需要加索引
• index 是全索引扫描，虽比 ALL 好但仍有优化空间

2. rows 数值过大

• 如果扫描上万甚至更多行，说明查询效率低
• 应结合 WHERE 条件和索引设计优化

3. Extra 字段中的警告信息

• Using filesort：需要排序但无法使用索引排序，性能差
• Using temporary：创建了临时表，常见于 GROUP BY 或 ORDER BY 操作
• Using where：正常，表示在存储引擎层后进行了过滤
• Using index：好消息，表示使用了覆盖索引，无需回表

使用 JSON 格式获取更详细信息

使用 EXPLAIN FORMAT=JSON 可获得更详细的执行信息，包括成本估算、索引使用细节等：

EXPLAIN FORMAT=JSON SELECT name FROM users WHERE age > 30 ORDER BY name;

返回的 JSON 中会包含：

• query_cost：总查询成本
• used_key：实际使用的索引
• filesort_information：排序方式是否利用索引
• attached_condition：附加的过滤条件

这些信息有助于判断是否需要调整索引或重写 SQL。

结合慢查询日志定位问题 SQL

开启慢查询日志，记录执行时间较长的语句：

SET long_query_time = 1;
SET slow_query_log = ON;

然后分析日志中耗时高的 SQL，用 EXPLAIN 检查其执行计划。配合 pt-query-digest 工具可批量分析慢查询。

基本上就这些。关键是养成写 SQL 后用 EXPLAIN 验证的习惯，关注 type、rows 和 Extra 字段，及时建立合适索引，避免全表扫描和临时排序。这样能有效发现并解决大多数性能瓶颈。不复杂但容易忽略。