mysql 中的 explain 命令是分析查询性能的重要工具，它通过显示执行计划帮助定位性能瓶颈。1. 关键字段包括 id（执行顺序）、select_type（查询类型）、type（连接类型，如 all、index）、key（实际使用索引）、rows（扫描行数）、extra（额外信息）；2. 常见性能问题有全表扫描、临时表和文件排序、不合理的连接顺序、未命中索引；3. 优化策略包括避免 select *、使用覆盖索引、拆分复杂查询、定期更新统计信息；4. 实战建议如改写导致索引失效的 sql、遵循最左匹配原则、结合慢查询日志分析等。掌握这些要点有助于提升查询效率。
MySQL 中的 EXPLAIN 命令是分析查询性能最直接、最常用的工具之一。它能帮助我们了解 MySQL 是如何执行一个 SQL 查询的，尤其是在面对复杂查询时，通过 EXPLAIN 的输出可以快速定位性能瓶颈所在。
一、看懂 EXPLAIN 输出的关键字段
当你在 SQL 前面加上 EXPLAIN，MySQL 会返回该查询的执行计划，而不是实际执行查询。关键字段包括：
- id：查询中每个 SELECT 的唯一标识符，值越大越先执行。
- select_type：查询类型，比如 SIMPLE（简单查询）、PRIMARY（主查询）、SUBQUERY（子查询）等。
- table：当前行涉及的表名。
- type：连接类型，非常重要。常见如 ALL（全表扫描）、index（遍历索引）、ref（使用非唯一索引）、eq_ref（唯一索引查找）等。
- possible_keys：可能使用的索引。
- key：实际使用的索引。
- rows：MySQL 认为需要扫描的行数，越小越好。
- Extra：额外信息，比如 “Using filesort”、“Using temporary” 等，这些通常意味着性能问题。
如果你看到 type 是 ALL，而且 rows 很大，那说明这个查询可能没有走索引或者走了错误的索引，需要优化。
二、识别常见的性能瓶颈点
使用 EXPLAIN 时，有几个典型问题你可能会遇到：
- 全表扫描（type = ALL）：这说明没有合适的索引可用。考虑在 WHERE 或 JOIN 字段上加索引。
- 临时表和文件排序（Extra 中出现 Using temporary 或 Using filesort）：这通常发生在 GROUP BY 或 ORDER BY 没有命中索引的情况下。
- 不合理的连接顺序：如果多个表连接，id 相同的行表示是同一组，执行顺序从上往下。如果驱动表选错了，会导致大量不必要的数据处理。
- 未命中预期索引（key 显示的是其他索引或 NULL）：即使建立了索引，也可能因为写法或统计信息不准而没被使用。
举个例子，你写了 WHERE create_time > '2024-01-01'，但 create_time 没有索引，那么 MySQL 就只能全表扫描。这时候加个索引就可能大幅提升效率。
三、如何结合业务场景优化查询
实际优化过程中，不能只盯着 EXPLAIN 的输出，还要结合具体业务逻辑来看：
- **避免 SELECT ***：只取需要的字段，减少 IO 和网络开销。
- 合理使用覆盖索引：如果一个查询只需要从索引中获取数据，不需要回表，效率会高很多。
- 拆分复杂查询：把一个多表关联的大查询拆成几个小查询，中间结果缓存起来，反而更快。
- 注意 LIMIT 的影响：有时候加了 LIMIT 可能会让执行计划看起来更高效，但不代表整体数据量小的时候也适用。
- 定期更新统计信息：特别是 InnoDB 表，如果统计信息不准，可能导致优化器选择错误的执行计划。
比如，一个订单查询涉及用户、商品、物流等多个表，你可以先查出订单 ID 列表，再分别去查其他表的数据，这样每个查询都比较轻量，也更容易利用索引。
四、实战建议与注意事项
下面是一些在使用 EXPLAIN 分析查询时的小技巧：
- 如果查询用了函数或表达式导致索引失效，尝试改写 SQL。
- 多列索引要遵循最左匹配原则，否则可能不会生效。
- 使用
EXPLAIN FORMAT=JSON可以获得更详细的执行计划信息。 - 对于慢查询日志中的语句，优先用
EXPLAIN分析。 - 不要迷信索引越多越好，索引也会带来写入负担。
例如，WHERE YEAR(create_time) = 2024 这种写法无法命中 create_time 上的索引，应该改成 create_time BETWEEN '2024-01-01' AND '2024-12-31'。
基本上就这些。用好 EXPLAIN 需要多练多看，理解执行计划背后的逻辑，才能真正发现并解决查询性能的问题。
