通过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 字段，及时建立合适索引，避免全表扫描和临时排序。这样能有效发现并解决大多数性能瓶颈。不复杂但容易忽略。
